[Python-Dev] Subsecond time stamps

[Guido van Rossum]

> >> 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/)