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)