On 5/29/19 7:34 AM, Stephen Colebourne wrote:
A hack was added to Joda-Time that reverses negative SAVE values which works so long as a rule set does not mix positive and negative save values. This is pretty awful as an approach because it is unreliable.
Does this hack suffice for Europe/Dublin? Europe/Dublin uses several rule sets, of which only one (the "Eire" rule set) uses negative save values, and the "Eire" rule set does not have positive save values. This makes it sound like Europe/Dublin should be OK for Joda-Time. I assume from your description that the hack does not suffice for Africa/Casablanca and Africa/El_Aaiun, as they use the Morocco rule set, and the Morocco rule set uses both positive save values (before 2019) and negative save values (for 2019 onwards). Would it help to split the Morocco rule set into two rule sets, say "OldMorocco" and "Morocco"? The former rule set would be for timestamps before 2019 and the latter would be for timestamps starting 2019. Although this change would complicate the 'africa' file a bit (as we'd have to add two zone continuation lines), the resulting TZif binary files should be identical and it sounds like it might be worth making such a change if it's the only thing preventing Joda-Time from working.
Proposal: Add an additional file with legacy versions of the rules that cause problems to downstream parsers.
The legacy file would be another file to maintain by hand. I prefer something more along the lines of the current approach, where the legacy files are generated automatically via "make rearguard_tarballs". Just today I received a report of success for someone using that approach with TZUpdater.