Mailman 3 September 2015 - Datetime-SIG

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 11:03 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > You need to use my zdump.py tool [1] to see it: > > $ ./python.exe Tools/tz/zdump.py Europe/Tallinn | grep 1999 > 1999-03-28 01:00:00 UTC = 1999-03-28 04:00:00 EEST isdst=1 +1 > 1999-10-31 01:00:00 UTC = 1999-10-31 03:00:00 EET isdst=0 -1 > 1999-10-31 22:00:00 UTC = 1999-11-01 00:00:00 EET isdst=0 +0 > > [1] : > https://github.com/abalkin/cpython/blob/issue24773-s3/Tools/tz/zdump.py > It looks like this problem has been fixed [2] in the 2015f release: $ ./python.exe Tools/tz/zdump.py /usr/local/etc/zoneinfo/Europe/Tallinn | grep 1999 1999-03-28 01:00:00 UTC = 1999-03-28 04:00:00 EEST isdst=1 +1 1999-10-31 01:00:00 UTC = 1999-10-31 03:00:00 EET isdst=0 -1 [2]: https://github.com/eggert/tz/commit/cf8df34364ffc9bd4eaddc5ff0d6bcdbd699893b

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 10:50 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > It fails on Europe/Tallinn which seems to have transitions separated by 22 > hours with the *same* utcoffset. > > I don't understand why zic would ever produce something like this. > Interestingly, system zdump misses the problem transition: $ zdump -v Europe/Tallinn | grep 1999 Europe/Tallinn Sun Mar 28 00:59:59 1999 UTC = Sun Mar 28 02:59:59 1999 EET isdst=0 Europe/Tallinn Sun Mar 28 01:00:00 1999 UTC = Sun Mar 28 04:00:00 1999 EEST isdst=1 Europe/Tallinn Sun Oct 31 00:59:59 1999 UTC = Sun Oct 31 03:59:59 1999 EEST isdst=1 Europe/Tallinn Sun Oct 31 01:00:00 1999 UTC = Sun Oct 31 03:00:00 1999 EET isdst=0 You need to use my zdump.py tool [1] to see it: $ ./python.exe Tools/tz/zdump.py Europe/Tallinn | grep 1999 1999-03-28 01:00:00 UTC = 1999-03-28 04:00:00 EEST isdst=1 +1 1999-10-31 01:00:00 UTC = 1999-10-31 03:00:00 EET isdst=0 -1 1999-10-31 22:00:00 UTC = 1999-11-01 00:00:00 EET isdst=0 +0 [1] : https://github.com/abalkin/cpython/blob/issue24773-s3/Tools/tz/zdump.py

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 10:28 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > So it seems a sufficient condition is that there's at most one UTC > offset change in the last 24 hours. Yes. That's the condition I've been talking for months about. If you have a chance, please take a look at https://github.com/abalkin/cpython/commit/d146830e70a1fda22380c5ba0d9592c16… It fails on Europe/Tallinn which seems to have transitions separated by 22 hours with the *same* utcoffset. I don't understand why zic would ever produce something like this.

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Tim Peters Sept. 26, 2015

Sept. 26, 2015

>>> https://github.com/abalkin/cpython/commit/54d3596b0180512c68c91e8308665c0a9… [Tim] >> Wondering whether this line: >> >> if probe2 != result + trans: >> >> could be replaced with: >> >> if probe2 == result: [Alex] > Yes, it can. Thanks for the suggestion. Good! So you have a simple, cross-platform solution now, at least for timestamps localtime() doesn't barf on. > The only assumption that it requires is that no fold is bigger than 24 hours. Well, it does rely on more than just that. For example, if there's a gap where the clock jumps from 2 to 3, followed soon after by a fold of an hour repeating times of the form 4:MM, then the second occurrence of 4:30 won't be detected as such.- the fold and the gap "cancel out" with respect to subtracting 24 hours in either naive time or timestamp time. So it seems a sufficient condition is that there's at most one UTC offset change in the last 24 hours. I wouldn't be surprised if that's always true now - or that it won't be after Kim Jong-un learns he could annoy us by making it false ;-)

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 26, 2015

Sept. 26, 2015

On Fri, Sep 25, 2015 at 5:32 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > > > https://github.com/abalkin/cpython/commit/54d3596b0180512c68c91e8308665c0a9… > > Wondering whether this line: > > if probe2 != result + trans: > > could be replaced with: > > if probe2 == result: > Yes, it can. Thanks for the suggestion. > > I'm not sure what the first line is saying ;-) It says that probe2 and result are on the opposite sides of the transition, but your tests is simpler and easier to understand.

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Tim Peters Sept. 25, 2015

Sept. 25, 2015

[Alex] > Based on the fold size statistic, I have implemented [1] a more robust > fold-detection algorithm that passes the exhaustive test. The only > assumption that it requires is that no fold is bigger than 24 hours. > > [1]: > https://github.com/abalkin/cpython/commit/54d3596b0180512c68c91e8308665c0a9… Wondering whether this line: if probe2 != result + trans: could be replaced with: if probe2 == result: I'm not sure what the first line is saying ;-) The second line says to me "this is the later time in a fold if and only if subtracting the width of the fold from the starting timestamp converts to the same local time - that's what 'the later time in a fold' means".

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 25, 2015

Sept. 25, 2015

On Wed, Sep 23, 2015 at 6:16 PM, Chris Angelico <rosuav(a)gmail.com> wrote: > I'm not sure whether this actually helps anything or not, ... Based on the fold size statistic, I have implemented [1] a more robust fold-detection algorithm that passes the exhaustive test. The only assumption that it requires is that no fold is bigger than 24 hours. [1]: https://github.com/abalkin/cpython/commit/54d3596b0180512c68c91e8308665c0a9…

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Tim Peters Sept. 25, 2015

Sept. 25, 2015

[Akira Li <4kir4.1i(a)gmail.com>] >> tzlocal module by Lennart Regebro might be good enough in practice >> https://github.com/regebro/tzlocal [Alex] > How well has it been tested on say FreeBSD or Solaris? I'm not sure it's relevant to what you're trying to do now. Lennart's tzlocal is intended to work with pytz, and its unix.py just searches all over creation for "the local" IANA tzfile to pass to pytz. My guess is that unless/until Python ships IANA files itself, we're best off sticking to standard C functions. Those have _some_ scant chance of working everywhere ;-)

1 0

Re: [Datetime-SIG] IANA TZ database statistics
by Akira Li Sept. 25, 2015

Sept. 25, 2015

Alexander Belopolsky <alexander.belopolsky(a)gmail.com> writes: > On Thu, Sep 24, 2015 at 2:42 PM, Random832 <random832(a)fastmail.com> wrote: > >> I still don't see the logic in doing any of this rather than parsing >> zoneinfo files directly on systems that use it; >> > > There is no portable way to even discover the location of the zoneinfo > files. (The default location when installing from the source is the > incredible /usr/local/etc/zoneinfo! ) If some location is guessed by > searching some likely candidates, there is no guarantee that this is what > system tzset() is using. tzlocal module by Lennart Regebro might be good enough in practice https://github.com/regebro/tzlocal

2 1

Re: [Datetime-SIG] IANA TZ database statistics
by Alexander Belopolsky Sept. 24, 2015

Sept. 24, 2015

On Thu, Sep 24, 2015 at 2:48 PM, Tim Peters <tim.peters(a)gmail.com> wrote: > > Get[Dynamic]TimeZoneInformation[ForYear] on Windows, etc. > > Presumably Alex doesn't want to devote his life to fleshing out "etc" > on endless platforms he doesn't use. It's worse than that. I have no desire to learn even what "Get[Dynamic]TimeZoneInformation[ForYear]" is. :-(

1 0