[Python-ideas] use gmtime(0) epoch in functions that use mktime()

[Guido van Rossum]

On Sat, Sep 6, 2014 at 2:56 PM, <random832 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140906/462c92ba/attachment.html>