Mailman 3 September 2015 - Datetime-SIG

Re: [Datetime-SIG] Adding PEP 495 support to dateutil
by Alexander Belopolsky Sept. 21, 2015

Sept. 21, 2015

On Fri, Sep 18, 2015 at 9:02 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > I happen to still believe that a "hybrid" tzinfo is the best approach, > but appreciate that pytz solved a world of problems with its approach > (while creating others). I really can't tell if a consensus has been > reached among the relative handful of datetime-SIG participants. > Which means there is no consensus. If "consensus" means "absence of sustained opposition" [1], it looks like we either weared out or intimidated the "opposition" enough for it not to be "sustained" anymore. :-) Luckily, PEP 495 solves at least one problem that has nothing to do with a choice of tzinfo: it makes the result of datetime.now() unambiguous. Also, the PEP does not take a position on what approach is better - it just makes both equally feasible. [1] https://lehors.wordpress.com/2008/08/07/what-consensus-means/

1 0

Re: [Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement
by Alexander Belopolsky Sept. 20, 2015

Sept. 20, 2015

On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > > PEP 495 [1] is a deliberately minimalistic proposal to remove an > ambiguity in representing some local times as datetime.datetime > objects. A major issue has come up since my announcement above. Tim Peters have noticed that PEP 495 would violate the "hash invariant" unless the fold attribute is accounted for in inter-zone comparisons. See [2] for details. This issue has been resolved by modifying the definition [3] of the "==" operator for aware datetimes with post-PEP tzinfo. Note that no program will be affected by this change unless it uses a post-PEP tzinfo implementation. I made some smaller changes [4] to the PEP as well and it should finally be ready for pronouncement. [1]: https://www.python.org/dev/peps/pep-0495 [2]: https://mail.python.org/pipermail/datetime-sig/2015-September/000625.html [3]: https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison [4]: https://hg.python.org/peps/log/39b7c1da05a2/pep-0495.txt

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 19, 2015

Sept. 19, 2015

On Sat, Sep 19, 2015 at 8:30 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > I remain unclear as to why it broke zic.c, though! > http://mm.icann.org/pipermail/tz/2014-March/020758.html

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 19, 2015

Sept. 19, 2015

On Sat, Sep 19, 2015 at 8:30 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > Maybe I should hand-code this rule as demo/test case. > > This is soooo sad - you're clearly becoming a timezone wonk ;-) No, I just want to close the timezone issue in Python once and for all. Despite its reputation, the issue is trivial: its all about a bunch of piecewise constant functions and very simple expressions like x + f(x). BTW, how do you like my new algorithm for inverting x + f(x)? https://github.com/abalkin/cpython/blob/7c30620c1789ee6ecead945513e2b34ce0c…

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Tim Peters Sept. 19, 2015

Sept. 19, 2015

[Alex] > Tim, are you referring to the "Troll" rule? [1] That's a strange beast > indeed and a comment above it says: > > # The CET-switching Troll rules require zic from tzcode 2014b or later, so > as > # suggested by Bengt-Inge Larsson comment them out for now, and approximate > # with only UTC and CEST. Uncomment them when 2014b is more prevalent. Yes, and this was pointed out some time ago. These really are the rules they use: http://www.timeanddate.com/time/zone/antarctica/troll > On the other hand, I don't see any challenges to PEP 495 there other than > finding means to extract the relevant information. The only problem is figuring out how to handle .dst() - which is a problem regardless of whether 495 is implemented. I remain unclear as to why it broke zic.c, though! > Maybe I should hand-code this rule as demo/test case. This is soooo sad - you're clearly becoming a timezone wonk ;-) > [1]: https://github.com/eggert/tz/blob/master/antarctica#L217

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 19, 2015

Sept. 19, 2015

On Sat, Sep 19, 2015 at 8:04 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > > > On Sat, Sep 19, 2015 at 6:01 PM, Tim Peters <tim.peters(a)gmail.com> wrote: >> >> that place in Antarctica with two kinds of DST each year. > > > I wonder, what's the point of saving daylight at the place where sun does not set? (or does not rise depending on the time of the year?) Tim, are you referring to the "Troll" rule? [1] That's a strange beast indeed and a comment above it says: # The CET-switching Troll rules require zic from tzcode 2014b or later, so as # suggested by Bengt-Inge Larsson comment them out for now, and approximate # with only UTC and CEST. Uncomment them when 2014b is more prevalent. On the other hand, I don't see any challenges to PEP 495 there other than finding means to extract the relevant information. Maybe I should hand-code this rule as demo/test case. [1]: https://github.com/eggert/tz/blob/master/antarctica#L217

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Tim Peters Sept. 19, 2015

Sept. 19, 2015

[Alex] > I wonder, what's the point of saving daylight at the place where sun does > not set? (or does not rise depending on the time of the year?) What's the point of DST _anywhere_? Politics :-) But in Antarctica, the base notion of "time zone" itself is essentially senseless: https://en.wikipedia.org/wiki/Time_in_Antarctica """ Antarctica sits on every line of longitude, due to the South Pole being situated near the middle of the continent. Theoretically Antarctica would be located in all time zones; however, areas south of the Antarctic Circle experience extreme day-night cycles near the times of the June and December solstices, making it difficult to determine which time zone would be appropriate. For practical purposes time zones are usually based on territorial claims; however, many stations use the time of the country they are owned by or the time zone of their supply base (e.g. McMurdo Station and Amundsen–Scott South Pole Station use New Zealand time due to their main supply base beingChristchurch, New Zealand).[1] Nearby stations can have different time zones, due to their belonging to different countries. Many areas have no time zone since nothing is decided and there are not even any temporary settlements that have any clocks. They are simply labeled with UTC time.[2] """ Then there's a list of "standard" UTC offsets for various Antarctica locations, varying from -4 to +12.

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 19, 2015

Sept. 19, 2015

On Sat, Sep 19, 2015 at 6:01 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > that place in Antarctica with two kinds of DST each year. > I wonder, what's the point of saving daylight at the place where sun does not set? (or does not rise depending on the time of the year?)

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Tim Peters Sept. 19, 2015

Sept. 19, 2015

[Alexander Belopolsky <alexander.belopolsky(a)gmail.com>] > The datetime.dst() and its namesake tzinfo.dst() [1] methods are required to > return a timedelta object that represents a quantity added to standard time > in a spring-forward transition. > > As explained in documentation, the dst() value is already incorporated in > the value returned by utcoffset() and is not needed in typical calculations. > Therefore, it is not surprising that both dateutil and pytz get it wrong in > some cases. [2,3] Ya, the docs over-promised here ;-) I think the only "important" invariant to maintain is that _some_ kind of DST is in effect if and only if .dst() != timedelta(0). > While pytz does slightly better than dateutil, it looks like it may not be > possible to derive the correct value of dst() from the compiled binary > tzfiles alone in all cases. You're right, it can't, but for a more general reason than what you give next: at base, it's impossible to always know what a zone's "standard offset" is from what a tzfile stores, even though the zoneinfo source (text) files do spell that out. > The problematic cases are transitions that involve a simultaneous change in > standard time and a DST transition. For example, Portugal switching from > CET to WEST in 1996. [2] Specifically, on 1996-03-31 that simultaneously switched from CET (standard time) to WEST (daylight time), yes? The total UTC offset was !;00:00 both before and after. In cases "like this", you can search either backward or forward in the transition list, to find a closest _different_ DST switch, and calculate a change of 1 hour either way. So it's "almost certain" that the DST offset is an hour in this case too. A case where that doesn't work, unless squinting: that place in Antarctica with two kinds of DST each year. The total UTC offset increases by 1 when the first DST kicks in, and by 1 again when the second kicks in. . So, in the second case, the delta between adjacent total UTC offsets is just 1, despite that the (total) DST offset is actually 2. Which suggests a more general "good guess": If the transition record says DST is not in effect, dst() should return timedelta(0). Else it says DST is in effect. If the prior transition record says it was not in effect and the total UTC offsets differ, .dst() should return their difference. Else the total offsets are the same, or DST is in effect for both. Search back to find the closest preceding time DST switched. Use the total UTC offset from the "not DST" half of that switch instead. If none can be found going backward, go forward instead. And if both searches fail, return timedelta(hours=1). > While the "SAVE" amount can be found in the raw tzdist files, this > information is lost when the raw files are compiled. The transition > information includes only the full new UTC offset and a boolean isdst flag. > If the transition is a pure DST transition, then dst() is just the > difference between the new UTC offset and the old, but if the standard time > offset changes at the time of the DST transition, there is no information in > the binary tzfile to split the full difference into standard time change and > DST adjustment. > > Unless I miss something, it looks like a high-quality tzinfo implementation > should extract the "SAVE" information from the raw files. I will continue to draw a distinction between "high quality" and "timezone wonk" quality ;-) > [1]: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.dst > [2]: https://github.com/dateutil/dateutil/issues/128 > [3]: https://bugs.launchpad.net/pytz/+bug/1497619

1 0

Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 19, 2015

Sept. 19, 2015

The datetime.dst() and its namesake tzinfo.dst() [1] methods are required to return a timedelta object that represents a quantity added to standard time in a spring-forward transition. As explained in documentation, the dst() value is already incorporated in the value returned by utcoffset() and is not needed in typical calculations. Therefore, it is not surprising that both dateutil and pytz get it wrong in some cases. [2,3] While pytz does slightly better than dateutil, it looks like it may not be possible to derive the correct value of dst() from the compiled binary tzfiles alone in all cases. The problematic cases are transitions that involve a simultaneous change in standard time and a DST transition. For example, Portugal switching from CET to WEST in 1996. [2] While the "SAVE" amount can be found in the raw tzdist files, this information is lost when the raw files are compiled. The transition information includes only the full new UTC offset and a boolean isdst flag. If the transition is a pure DST transition, then dst() is just the difference between the new UTC offset and the old, but if the standard time offset changes at the time of the DST transition, there is no information in the binary tzfile to split the full difference into standard time change and DST adjustment. Unless I miss something, it looks like a high-quality tzinfo implementation should extract the "SAVE" information from the raw files. [1]: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.dst [2]: https://github.com/dateutil/dateutil/issues/128 [3]: https://bugs.launchpad.net/pytz/+bug/1497619

1 0