[Datetime-SIG] Calendar vs timespan calculations...

[Alexander Belopolsky]

On Mon, Aug 3, 2015 at 11:32 AM, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> wrote:
>> I'm happy with a strict tzinfo at least having the ability to deal with leap seconds -- then those that care can make it work.
>
> I'm a bit confused about what the strict tzinfo object has to do with
> leap seconds.
>
> Leap seconds are more like leap years than DST transitions. (Except
> that we don't know when they will occur in the future). An extra
> second (:60) is added, rather than repeating one. So it is never
> ambiguous what is meant.

Yes, but if instead of having February 29, people decided that they
would have two February 28s every four years, they would have the same
calendar in all other days, but computers would have an issue similar
to what we have at the end of DST.  Even though the rest of the world
spells the leap second as 23:59:60, we can spell it as
23:59:59(repeated) and represent as time(23, 59, 59, first=False).
This is nothing but notation.  (Note that there is no spelling for
these times as POSIX "seconds since EPOCH", so if we try to map them
to POSIX timestamps we will have to repeat a second.)  A timezone that
implements 23:59:59 + 1s = 23:59:60 and 23:59:60 + 1s = 00:00:00 can
just as easily implement 23:59:59 + 1s = 23:59:59(repeated) and
23:59:59(repeated) + 1s = 00:00:00.

The advantage of the flag over extending the range of minutes is that
the added flag will be ignored by the older programs that will
continue to function producing results that may be off by 1s, but will
not crash with "ValueError: second must be in 0..59".