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

[Chris Barker]

On Mon, Aug 3, 2015 at 8:54 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

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


sure, but that's not what's done.


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

well, yes and no -- we can do whatever we want internally, but if we're
going to print out the datetime in iso 8601 format, or whatever, shouldn't
we do it offical UTC way??? And the 60 second thing is actually easier, not
harder (Not ambiguous).


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


well, there is the POSIX problem no matter how it's handled.


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

Maybe I'm getting hung up on purity over practicality -- but this sure seem
slike logic that should not be in the timezone object -- it has nothing to
do with time zones. (I suppose the logic can go in the string_tzinfo base
class, and it's easily shared, but it sure does feel like the wrong place
to put it.) And since I don't think anyone is actually proposing to
implement this yet anyway, why not keep tzinfo clean -- and put leap
seconds in datetime if and when it's decided that that's a good idea.

-CHB


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





-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150803/1c3eda07/attachment.html>