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 -