[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

[Guido van Rossum]

On Sun, Aug 16, 2015 at 8:02 PM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> On Sun, Aug 16, 2015 at 10:29 PM, Guido van Rossum <guido at python.org>
> 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.
>

Good point, but I do have an opinion here, which is that we should not
bless such abuse. There are other interpretations and uses of POSIX
timestamps, and certainly the time module promises that (except when the
clock is adjusted by root) time.time() ticks monotonically and measures
(approximate, but close) real seconds. This is the reason for Google's
"smearing" of leap seconds -- interval timers and the like based on the
system clock continue to work.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150816/94dd04bb/attachment.html>