>>> from os import stat, utime
>>> utime('fi.txt', (1099285201, 1099210995))
>>> stat('fi.txt').st_atime
1099285200
>>> stat('fi.txt').st_mtime
1099210996

Logged In: YES 
user_id=31435

Are you using FAT32 (or FAT) as your file system?  If so, 
those record file write times to 2-second resolution, so it's 
not a coincidence that the times you get back are always 
even.

Logged In: YES 
user_id=80475

Yes.  There is a two second resolution.
It looks like mtime is updating but not atime:


>>> from os import stat, utime
>>> stat('fi.txt')
(33206, 0L, 2, 1, 0, 0, 14225L, 1099285200, 1099210600,
1099210993)
>>> utime('fi.txt', (1099285900, 1099210800))
>>> stat('fi.txt')
(33206, 0L, 2, 1, 0, 0, 14225L, 1099285200, 1099210800,
1099210993)

Logged In: YES 
user_id=752496

Same behaviour here (not updates atime): Win2K SP4, on Fat32...

Logged In: YES 
user_id=31435

It's specifically *write* times that have a 2-second resolution 
on FAT, and write times are what I guess are important for 
the traceback test.

*Access* time has stinking 1-day resolution on FAT (no 
kidding).  So, since I figure I'm in the same time zone as 
Raymond, and FAT stores file times in local time (but NTFS 
uses UTC), it's not a coincidence either that the hour, minute 
and second fields are all 0 here (using the access time 
Raymond got):

>>> time.localtime(1099285200)
(2004, 11, 1, 0, 0, 0, 0, 306, 0)

You would have to feed utime an access time at least a day 
removed from that to conclude that utime doesn't change 
access time on FAT.  The access time you tried to set was 
also a local time on 2004 Nov 01:

>>> time.localtime(1099285900)
(2004, 11, 1, 0, 11, 40, 0, 306, 0)

so it's expected that you'd lose the 0:11:40 part on FAT -- 
and you did.

IOW, there's not yet evidence here that os.utime() doesn't 
work as well as it possibly can with a FAT filesystem.

File times on Windows are a godawful mess.  For more fun, 
see the docs:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/sysinfo/base/file_times.asp

Logged In: YES 
user_id=752496

utime() works; you just' need to specify a greater time change.

I propose to close this bug and update the utime docs with
something like:

"Be aware that the resolution of the specified time depends
of the filesystem (for example, in FAT32 the access time has
a 1-day resolution: you'll not be able to specify the atime
with more detail than that)".

Logged In: YES 
user_id=80475

! day!
Unbelievable.

Logged In: YES 
user_id=31435

I checked in doc changes for utime() and stat(), for Python 
2.4, so closing this report.