On Sat, Sep 6, 2014 at 2:56 PM, <random832@fastmail.us> wrote:
On Sat, Sep 6, 2014, at 13:06, Guido van Rossum wrote:
There used to be systems with a different notion of epoch. Are there still such systems around? OSX has the UNIX epoch -- what's it gmtime(0) on Windows?
If you call the time.h functions from the CRT library, they use 1970 (and always have). Windows has _other_ functions that use a different epoch (1600, if I remember correctly), but they're native win32 functions not called directly by python.
The wrinkle you get on windows is that most of the functions don't work with *negative* time_t values (or struct tm values representing dates before 1970), and/or some other arbitrary cutoff dates. In particular, time.localtime gives an OSError on negative values, but time.gmtime gives an OSError on values below -43200, and both give errors if passed a value representing a year above 2999, and strftime does not accept years above 9999.
But, as I've advocated before, there's no fundamental reason that python should chain itself to the C library's underlying implementation rather than defining its own time functions that do always use an epoch of 1970, and handle leap seconds consistently, have unlimited range, etc.
I'm fine with that, as long as "handle leap seconds consistently" means "pretend they don't exist" (which is necessary for compatibility with POSIX). But it sounds like a big coding project. Fixing the docs to be consistent and correctly describe the current implementation may be simpler. -- --Guido van Rossum (python.org/~guido)