> >> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4