On zaterdag, september 7, 2002, at 09:35 , Martin v. Loewis wrote:
Guido van Rossum
writes: Hm, so maybe new field names is still the way to go. E.g. st_mtime gives an int, st_mtimef gives a float. The tuple version only gives the int. If the system doesn't support subsecond resolution, the st_mtimef field still exists but is an int (no point allocating a float and converting the int).
OTOH, I just found that the time values are already floats on the Mac. Did the change in return value for time.time() cause any problems at the time it was made?
It's been causing me headaches in the form of failing test
suites about once a year:-) But if I break down the time
problems I have on the Mac (100% of which are due to people
having a completely unix-centric idea of what a timestamp is) I
would say 90% are due to the Mac epoch being in 1904 in stead of
in 1970, 9% are due to mac timestamps being localtime in stead
of GMT and only 1% are due to the timestamps being floats. And
the latter are the easiest to fix, too. The localtime/gmt issues
are the hardest, especially because of DST.
My preference would be that st_mtime and all other such values
are defined to be cookies (sort of similar to lseek values). You
would then invoke one of the mythical Python datetime routines
to convert the cookie into something guaranteed to be of your
liking. (and this specific datetime routine would be platform
dependent). If you use the cookie as-is you have a good chance
of it working, but you're living dangerously (an analogy would
be opening a binary file without "rb"). But this isn't very
friendly for backwards compatibility...
--
- Jack Jansen