On Mon, Aug 3, 2015 at 8:54 AM, Alexander Belopolsky < [email protected]> 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 [email protected]
_______________________________________________ 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/
