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

[random832 at fastmail.us]

On Sat, Sep 6, 2014, at 18:19, Guido van Rossum wrote:
> 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).

Consistently pretend they don't exist. AFAIK you're more likely to
encounter a system using the so-called "right" timezones in tzdata (and
therefore _not_ pretending that leap seconds don't exist) than one which
doesn't have an epoch of 1970. In which case you would need to use
"time2posix" and "posix2time" when calling any platform-specific
functions that use time_t (with the user-visible python side, of course,
being the non-leap-second posix timestamps)


I did an inventory of names in the time module, by whether they can be
implemented platform-independently or not:

Depends on system-dependent ways of getting the current time:
    clock
    clock_getres
    clock_gettime
    clock_settime
    get_clock_info
    monotonic
    perf_counter
    process_time
    time
    Various default values (gmtime etc), can be implemented in terms of
    time

Depends on system-dependent ways of getting the local timezone:
    ctime, can be implemented in terms of localtime
    localtime
    mktime
    tzset, can be used to set constants:
        timezone
        tzname
        altzone
        daylight

Otherwise system-dependent:
    sleep

Can be implemented in a platform-independent or pure python way:
    asctime
    gmtime
    calendar.timegm
    strftime (except %z %Z and locale)
    strptime (except %Z and locale)
    struct_time



The list of theoretically platform-independent functions is, as it turns
out, depressingly small.

It might also be worthwhile to make a windows-specific implementation of
some of the platform-dependent functions, rather than one relying on the
C library (for example, localtime only has a range of 1970 to 2199,
whereas SystemTimeToTzSpecificLocalTime has a range of 1601 to 30828.)
But it would have the issue of not having the C library's somewhat
obscure support of part of the POSIX TZ standard. (However, a full
implementation of POSIX TZ could be done in a platform-independent way).