[Python-Dev] Subsecond time stamps
Guido van Rossum
Sat, 07 Sep 2002 19:24:54 -0400
> >> 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.
I'm not sure if this can be used as an argument for making st_mtime
and friends floats and be done with it. I wish it could be, because
in the long run that's a much nicer API than adding new fields.
> 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...
There's at least one place I know of in Python that assumes the epoch
being 1970: calendar.timegm() -- note the line "EPOCH = 1970" right in
front of it. :-)
Would it make sense if the portable Python APIs translated everything
to an epoch of 1970 and UTC? That's what the Windows C library does.
Very helpful. (Or is this a problem that's going to disappear with
MacOS X? I presume it uses UTC and I hope its epoch is 1970?)
--Guido van Rossum (home page: http://www.python.org/~guido/)