Discrepancies in time zone data interpretation at standard offset changes
Heads up for Stephen Colebourne: this post highlights a discrepancy between Joda Time and tzdump, so you may want to read carefully :) This is in relation to my earlier message about the text format. My confusion here is the reason I'm anxious to see canonical data :) Currently, both Joda Time and Noda Time have some interesting code when working out the transitions for a time zone which checks whether the later transition occurs at the same *local* time as the earlier transition, and if so extends the earlier transition to consume the later one. I've worked out that this is basically to handle an oddity that sometimes occurs when standard offsets change. One example of a zone in which this happens is America/Juneau. Here are the zone lines from 2015e, and I've highlighted the ones we're immediately concerned with: Zone America/Juneau 15:02:19 - LMT 1867 Oct 18 -8:57:41 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 -8:00 US P%sT 1946 -8:00 - PST 1969 -8:00 US P%sT 1980 Apr 27 2:00 -9:00 US Y%sT 1980 Oct 26 2:00 * -8:00 US P%sT 1983 Oct 30 2:00* * -9:00 US Y%sT 1983 Nov 30* -9:00 US AK%sT The US rules in force at the time are: Rule US 1967 2006 - Oct lastSun 2:00 0 S Rule US 1976 1986 - Apr lastSun 2:00 1:00 D So, the first bolded zone line comes to an end at the instant of the transition into standard time, while standard time is -8 (so a wall offset of -7). I assume this transition should *not* be included in the eventual set of transitions (i.e. the bound given is exclusive). This would occur at 1983-10-30T09:00Z. Now, in the second bolded zone line, the standard offset is -9 instead, so the transition into daylight saving time would occur at 1983-10-30T10:00Z. So looking at the rules in a naive way, residents of Juneau would have to change their watches twice on October 30th 1983. At 2am they'd put their watches back an hour to account for the change in standard time (but still be in daylight saving time)... and then when it next hit 2am they'd put their watches back *another* hour to account for the transition into standard time. Now, I'm pretty sure that's not what's intended, and indeed zdump shows just a single transition setting local time back two hours at 1983-10-30T09:00Z: America/Juneau Sun Oct 30 08:59:59 1983 UTC = Sun Oct 30 01:59:59 1983 PDT isdst=1 America/Juneau Sun Oct 30 09:00:00 1983 UTC = Sun Oct 30 00:00:00 1983 YST isdst=0 ... whereas Noda Time (and, I've just checked, Joda Time) have a single transition at 1983-10-30T10:00Z instead. Is it documented somewhere what should happen in this case? (As a side question, is there a single canonical place documenting the time zone data format? I've found various sources over the years, but it would be nice to have somewhere canonical - ideally either within each release or on the IANA home page. The Theory file gives a lot of interesting more abstract information, but a single place saying "Here is what each file in the release means, with details of its format" would be very welcome. Apologies if it already exists and I've just missed it...) Jon
On Jul 11, 2015, at 8:06 AM, Jon Skeet <skeet@pobox.com> wrote:
Heads up for Stephen Colebourne: this post highlights a discrepancy between Joda Time and tzdump, so you may want to read carefully :)
This is in relation to my earlier message about the text format. My confusion here is the reason I'm anxious to see canonical data :)
Currently, both Joda Time and Noda Time have some interesting code when working out the transitions for a time zone which checks whether the later transition occurs at the same local time as the earlier transition, and if so extends the earlier transition to consume the later one.
I've worked out that this is basically to handle an oddity that sometimes occurs when standard offsets change. One example of a zone in which this happens is America/Juneau. Here are the zone lines from 2015e, and I've highlighted the ones we're immediately concerned with:
Zone America/Juneau 15:02:19 - LMT 1867 Oct 18 -8:57:41 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 -8:00 US P%sT 1946 -8:00 - PST 1969 -8:00 US P%sT 1980 Apr 27 2:00 -9:00 US Y%sT 1980 Oct 26 2:00 -8:00 US P%sT 1983 Oct 30 2:00 -9:00 US Y%sT 1983 Nov 30 -9:00 US AK%sT
The US rules in force at the time are:
Rule US 1967 2006 - Oct lastSun 2:00 0 S Rule US 1976 1986 - Apr lastSun 2:00 1:00 D
So, the first bolded zone line comes to an end at the instant of the transition into standard time, while standard time is -8 (so a wall offset of -7). I assume this transition should not be included in the eventual set of transitions (i.e. the bound given is exclusive). This would occur at 1983-10-30T09:00Z.
Now, in the second bolded zone line, the standard offset is -9 instead, so the transition into daylight saving time would occur at 1983-10-30T10:00Z.
So looking at the rules in a naive way, residents of Juneau would have to change their watches twice on October 30th 1983. At 2am they'd put their watches back an hour to account for the change in standard time (but still be in daylight saving time)... and then when it next hit 2am they'd put their watches back another hour to account for the transition into standard time. Now, I'm pretty sure that's not what's intended, and indeed zdump shows just a single transition setting local time back two hours at 1983-10-30T09:00Z:
America/Juneau Sun Oct 30 08:59:59 1983 UTC = Sun Oct 30 01:59:59 1983 PDT isdst=1 America/Juneau Sun Oct 30 09:00:00 1983 UTC = Sun Oct 30 00:00:00 1983 YST isdst=0
... whereas Noda Time (and, I've just checked, Joda Time) have a single transition at 1983-10-30T10:00Z instead.
Is it documented somewhere what should happen in this case? (As a side question, is there a single canonical place documenting the time zone data format? I've found various sources over the years, but it would be nice to have somewhere canonical - ideally either within each release or on the IANA home page. The Theory file gives a lot of interesting more abstract information, but a single place saying "Here is what each file in the release means, with details of its format" would be very welcome. Apologies if it already exists and I've just missed it…)
This looks a lot like my question here: http://mm.icann.org/pipermail/tz/2015-June/022293.html which Paul answered to my satisfaction with: http://mm.icann.org/pipermail/tz/2015-June/022294.html He also clarified the zic man page a bit on this issue: https://github.com/eggert/tz/commit/0c8b5ba8393d85b2cbb38bf75045cc84b2d26925 Using that answer I am also coming up with this single transition for American/Juneau: 1983-10-30 08:59:59 = 1983-10-30 01:59:59 PDT 1983-10-30 09:00:00 = 1983-10-30 00:00:00 YST As a bug-finding exercise for my own parser I scanned the entire database for all transitions that occurred within 24hrs of the last one, and tripped over about a dozen. Most of those revealed bugs in my parser. The rest were not actually bugs in the data, but rather what I would call minor inefficiencies in the data which Paul cleaned up for me: https://github.com/eggert/tz/commit/0e2e3ece543cdbbfc76c1d103b6c6d63b1b54649 https://github.com/eggert/tz/commit/cf8df34364ffc9bd4eaddc5ff0d6bcdbd699893b Howard
participants (2)
-
Howard Hinnant -
Jon Skeet