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