[Python-Dev] Subsecond time stamps

[Jack Jansen]

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 -