Fix major incompatibility with tzdata 2026c (Morocco, Alberta Canada) - #178
Open
dyl-sv wants to merge 1 commit into
Open
Fix major incompatibility with tzdata 2026c (Morocco, Alberta Canada)#178dyl-sv wants to merge 1 commit into
dyl-sv wants to merge 1 commit into
Conversation
Background on the data: the IANA time zone database describes each zone as a stack of "zone lines". Each line covers a span of history — it gives the base offset and which daylight-saving rules apply — and ends on a date when the next line takes over. Importantly, the daylight-saving rules a line points at can stop firing before the line's own end date. In tzdata 2026c, Morocco switches to permanent UTC on 20 September 2026. The zone line for Africa/Casablanca and Africa/El_Aaiun applies a +01 base offset with Morocco's daylight-saving rules and runs until that September switch. But those rules stop in March 2026, after the year's final Ramadan adjustment — so the line has six months left to run with no more rules. PeriodBuilder assumed a zone line ended the moment its rules stopped, so it switched Morocco to permanent UTC in March instead of September. That dropped the +01 span from March to September: any instant in that window was reported as UTC — one hour off — for roughly six months. The fix: when a zone line's rules run out but the line itself keeps going, hold the offset the last rule left in effect until the line's real end date, then move on to the next line. This only kicks in for lines with a fixed end date, so zones whose final line runs forever (and hand off to dynamically computed future periods) are unaffected. The same mistake also affected historical transitions in a number of other zones. Verified against zdump: 78 previously-wrong transitions now match, with no regressions.
dyl-sv
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #177
PeriodBuilder assumed a zone line ended the moment its rules stopped, so it switched Morocco to permanent UTC in March instead of September. That dropped the +01 span from March to September: any instant in that window was reported as UTC — one hour off — for roughly six months.
The fix: when a zone line's rules run out but the line itself keeps going, hold the offset the last rule left in effect until the line's real end date, then move on to the next line. This only kicks in for lines with a fixed end date, so zones whose final line runs forever (and hand off to dynamically computed future periods) are unaffected.
The same mistake also affected historical transitions in a number of other zones. Verified against zdump: 78 previously-wrong transitions now match, with no regressions.
Credit: @kamilkowalski