On Tue, Aug 4, 2015 at 12:13 PM, Chris Barker <[email protected]> wrote: >> On Aug 3, 2015, at 9:11 PM, Tim Peters <[email protected]> wrote: >> >> Sorry about this. I don't want to talk about leap seconds anymore, > > Nor do I, but > > TL;DR -- leap seconds are in the definition of UTC.
I have not reflected this in the PEP, but in the reference implementation, I am toying with the following bit of "leap seconds support": diff --git a/Lib/datetime.py b/Lib/datetime.py .. - ss = min(ss, 59) # clamp out leap seconds if the platform has them - return cls(y, m, d, hh, mm, ss, us) + ss, first = (ss, True) if ss < 60 else (59, False) + return cls(y, m, d, hh, mm, ss, us, first=first) .. See <https://github.com/abalkin/cpython/commit/a54ab4502b9b50ae87d7795930fd13e70dbb17fa>. Note that even though many people claim that POSIX does not support leap seconds, this is only true with respect to the time_t timestamps and does not apply to the broken down tm structure which is more directly related to Python datetime than "seconds since EPOCH." To the contrary, leap seconds support is mandated by POSIX in the case of struct tm: """ The <time.h> header shall declare the structure tm, which shall include at least the following members: int tm_sec Seconds [0,60]. ... The range [0,60] for tm_sec allows for the occasional leap second. """ See <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html>. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
