[Python-Dev] Subsecond time stamps (original) (raw)

Guido van Rossum guido@python.org
Sat, 07 Sep 2002 19:24:54 -0400

>> Hm, so maybe new field names is still the way to go. E.g. stmtime >> gives an int, stmtimef gives a float. The tuple version only gives >> the int. If the system doesn't support subsecond resolution, the >> stmtimef 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 stmtime 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/)