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

[Akira Li]

Guido van Rossum <guido at python.org> writes:

> 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.

datetime doesn't support leap seconds. That part is already implemented ;)

I've submitted a documentation patch that explicitly mentions the
assumption about 1970 epoch -- https://bugs.python.org/issue22356

Does it make sense to submit other patches that only matter if
the epoch is not 1970?


---
Unrelated: it is possible to convert between POSIX time and UTC without
knowing leap seconds:

  posix_time = (utc_time - datetime(1970, 1, 1)) // timedelta(seconds=1)

It is the exact relation.

TAI is one bisect() call away from UTC if the list of leap seconds (such
as provided by the tz database (used in pep 431)) is known. It is
available on all modern OSes (including Windows [1]).

[1] http://www.iana.org/time-zones/repository/tz-link.html


--
Akira