[tz] Java & Rearguard

[Paul Eggert]

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.