Mailman 3 August 2015 - Datetime-SIG

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Ethan Furman Aug. 3, 2015

Aug. 3, 2015

On 08/02/2015 01:42 PM, Łukasz Rekucki wrote: > I didn't hear about *Google* shutting down for hours. I do believe the > leap second problem can be solved on a OS-level instead of having to > fix all applications in the world. Fair point about Google. 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. -- ~Ethan~

4 4

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Alexander Belopolsky Aug. 3, 2015

Aug. 3, 2015

On Mon, Aug 3, 2015 at 2:00 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > A "timezone" _now_ should really be defined as an offset from TAI Unfortunately, they will first have to rename it to ITA as a compromise between French TAI and English IAT and since there are three more permutations of these three letters, this problem will stay forever in the subcommittees.

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Tim Peters Aug. 3, 2015

Aug. 3, 2015

[Chris Barker] >> 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. [Alexander Belopolsky] > It has everything to do with timezones. The information about > historical addition of leap seconds is and will be distributed with > the timezone databases. This is what Olson's distribution has always > done and what IANA intends to continue. See [1] for more details. > > [1]: https://tools.ietf.org/html/draft-ietf-tzdist-service-11#section-5.6 A "timezone" _now_ should really be defined as an offset from TAI, the one remaining scheme that remains - and always will remain - utterly uniform. Then it would make perfect sense to everyone that the history of UTC leap seconds, which are changes to UTC's offset from TAI, belong in timezone logic. Then again, everything looks simple to me - LOL ;-)

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Alexander Belopolsky Aug. 3, 2015

Aug. 3, 2015

On Mon, Aug 3, 2015 at 12:49 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: > if we're going to print out the datetime in iso 8601 format, or whatever, > shouldn't we do it offical UTC way??? Maybe we should, but we don't. Try the following on a Linux system: $ TZ=right/UTC python >>> datetime.datetime.utcfromtimestamp(1341100823).isoformat() '2012-06-30T23:59:59' >>> datetime.datetime.utcfromtimestamp(1341100824).isoformat() '2012-06-30T23:59:59' >>> datetime.datetime.utcfromtimestamp(1341100825).isoformat() '2012-07-01T00:00:00'

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Alexander Belopolsky Aug. 3, 2015

Aug. 3, 2015

On Mon, Aug 3, 2015 at 12:49 PM, Chris Barker <chris.barker(a)noaa.gov> wrote: > >> >> 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. It has everything to do with timezones. The information about historical addition of leap seconds is and will be distributed with the timezone databases. This is what Olson's distribution has always done and what IANA intends to continue. See [1] for more details. [1]: https://tools.ietf.org/html/draft-ietf-tzdist-service-11#section-5.6

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Chris Barker Aug. 3, 2015

Aug. 3, 2015

On Mon, Aug 3, 2015 at 8:54 AM, Alexander Belopolsky < alexander.belopolsky(a)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(a)noaa.gov

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Alexander Belopolsky Aug. 2, 2015

Aug. 2, 2015

On Sun, Aug 2, 2015 at 4:26 PM, Łukasz Rekucki <lrekucki(a)gmail.com> wrote: > But if we don't write a one, how do we know it's possible to do? IMHO, > the same approach was taken for tzinfo and DST and it didn't work out > very well. This is unfair. Python included extensively tested tzinfo implementations in its documentation and the test suit from the very beginning. Third party libraries came up with their own more complete implementations and even addressed some of the limitations inherent in the original design. Overall, I don't think Python's history of timezone support is any worse that that of any other language of its age.

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Ethan Furman Aug. 2, 2015

Aug. 2, 2015

On 08/02/2015 01:26 PM, Łukasz Rekucki wrote: > Most times you need leap seconds, is to ignore them (as Tim described > in his trading stock example). Adding support to a single programming > language and fixing it every application, won't make the world better. > Instead, you can use UTC-SLS or do what Google did. You mean to shut down the markets around the time of the leap second? Or risk other systems shut down for hours? That strikes me as a massive failure of software. -- ~Ethan~

2 1

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Łukasz Rekucki Aug. 2, 2015

Aug. 2, 2015

On 2 August 2015 at 21:19, Guido van Rossum <guido(a)python.org> wrote: > On Sun, Aug 2, 2015 at 8:52 PM, Ethan Furman <ethan(a)stoneleaf.us> wrote: >> >> On 08/02/2015 10:32 AM, Łukasz Rekucki wrote: >> >>> I don't have much time to respond now, but please don't add leap seconds. >>> People >>> are actively working to get rid of them entirely and they are never >>> useful on the >>> business level which this module is aimed at. >> >> >> I don't know whether we should add support for leap-seconds to the new >> strict tzinfo, but I will mention that the proposal to get rid of them keeps >> being postponed, and leap seconds are actively harming the business >> community precisely because they are not being accounted for. > > > I like the idea of using a special tzinfo to reveal the leap seconds for > those who really want them. (And we won't have to provide such a tzinfo -- > it's enough that one could be written, given a table of leap seconds.) > But if we don't write a one, how do we know it's possible to do? IMHO, the same approach was taken for tzinfo and DST and it didn't work out very well. For example, I probably could implement a timezone which represents TAI (assuming I have always up-to-date leap seconds table), but it is not possible because tzinfo.utcoffset() requires me to return an integer number of minutes. Most times you need leap seconds, is to ignore them (as Tim described in his trading stock example). Adding support to a single programming language and fixing it every application, won't make the world better. Instead, you can use UTC-SLS or do what Google did. [1]: http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ -- Łukasz Rekucki

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Akira Li Aug. 2, 2015

Aug. 2, 2015

Łukasz Rekucki <lrekucki(a)gmail.com> writes: R> On Sunday, August 2, 2015, Alexander Belopolsky < > alexander.belopolsky(a)gmail.com > <javascript:_e(%7B%7D,'cvml','alexander.belopolsky(a)gmail.com');>> wrote: > >> On Sun, Aug 2, 2015 at 9:46 AM, Guido van Rossum <guido(a)python.org> wrote: >> > There's a simpler reason for ignoring leap seconds in datetime: Python's >> > wall clock is mappable to POSIX timestamps, which also ignore leap >> seconds >> > (the reason being Tim's long explanation :-). >> >> Note that if you combine several recently made proposals, you can have >> a fully backward-compatible solution for leap seconds. > > > I don't have much time to respond now, but please don't add leap seconds. > People are actively working to get rid of them entirely and they are never > useful on the business level which this module is aimed at. > "never useful on the business level" -- you can't guarantee that your input won't contain a leap second e.g., 2012-06-30 23:59:60.209215 see http://stackoverflow.com/questions/21027639/python-datetime-not-accounting-… Currently, datetime does not merely ignores leap seconds. It's hostile to them. I don't understand why do I have to write: import time from calendar import timegm from datetime import datetime, timedelta time_string = '2012-06-30T23:59:60.209215' time_string, dot, us = time_string.partition('.') utc_time_tuple = time.strptime(time_string, "%Y-%m-%dT%H:%M:%S") dt = datetime(1970, 1, 1) + timedelta(seconds=timegm(utc_time_tuple)) if dot: dt = dt.replace(microsecond=datetime.strptime(us, '%f').microsecond) print(dt) # -> 2012-07-01 00:00:00.209215 Instead of a simple: from datetime import datetime time_string = '2012-06-30T23:59:60.209215' dt = datetime.strptime(time_string, "%Y-%m-%dT%H:%M:%S.%f") print(dt) # -> 2012-07-01 00:00:00.209215 If datetime can't represent UTC time (a leap second) then it should behave like a broken-down POSIX time consistently: the same datetime object may refer to a different UTC time i.e., datetime(2012, 7, 1) may refer to both 2012-07-01UTC and 2012-06-30 23:59:60UTC like 1341100800 POSIX time does: 2012-07-01UTC -> 1341100800 2012-06-30 23:59:60UTC -> 1341100800 and in reverse: 1341100800 -> 2012-07-01UTC Related: http://bugs.python.org/issue23574

1 0