On Sun, Aug 16, 2015 at 10:29 PM, Guido van Rossum <[email protected]> wrote: > To me, we're talking about a mapping to POSIX timestamps, which use a > straightforward algorithm to map compute the date and time -- in particular, > divmod(ts, 86400) will give the day number and the second within that day. > The day gets converted to a date using standard calendar math (assuming they > eventually fix the standard so that 2100 is not considered a leap year :-) > and the time gets converted to HH:MM:SS using even simpler calculations. > There's no room for leap seconds there.
In PEP-0500, I don't talk about POSIX timestamps at all. To me, POSIX timestamps are just a compressed encoding for YYYY-MM-DD hh-mm-ss names of various points in time. The encoding is so efficient that there is no room between 2015-06-30 23:59:59 and 2015-05-01 00:00:00. Yes, it is very convenient that in most cases naive integer operations on POSIX timestamps translate to real world time time operations, but this is the same as the convenience of having 'a' + 1 produce 'b' in C. Once you face the realities of Unicode, you have to give up this convenience. If PEP 495 is accepted, then unlike POSIX timestamps, datetime instances will have enough redundancy to encode 2015-06-30 23:59:60 (as the second 2015-06-30 23:59:59) and not step over any otherwise valid time. Whether or not we should bless such abuse of the first flag, is a separate question, but the possibility will be there for the third party libraries to explore. _______________________________________________ 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/
