[tz] Discrepancies in time zone data interpretation at standard offset changes

[Howard Hinnant]

> On Jul 11, 2015, at 8:06 AM, Jon Skeet <skeet at 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