[Python-Dev] Subsecond time stamps
Jack Jansen
Jack.Jansen@oratrix.com
Sun, 8 Sep 2002 00:11:36 +0200
On zaterdag, september 7, 2002, at 09:35 , Martin v. Loewis wrote:
> Guido van Rossum <guido@python.org> 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 <Jack.Jansen@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution --
Emma Goldman -