On Wed, 29 May 2019 at 18:05, Paul Eggert <eggert@cs.ucla.edu> wrote:
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.
The hack added for Joda-Time is such that the current data format can be parsed correctly for all zones. It also handles the "Apr Sun>=25" type rules recently added. It is perfectly possible to add the same hack to ThreeTen-Backport and TZUpdater, I'm simply indicating that it *is* a hack, and the problem is not going to go away.
Would it help to split the Morocco rule set into two rule sets, say "OldMorocco" and "Morocco"?
No, that wouldn't really help. (I thought about such solutions, but both the Rule and Zone lines are affected by negative SAVE values.) And the parser can handle the Morocco rules. IIRC, the problem would be if there is a Zone line where rules apply with both positive and negative SAVE values. This doesn't happen with Morocco because there is a zone line starting at the end of 2018.
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".
In essence the choice for downstream parsers is a) a hack to try and reverse engineer the desired data b) rely on rearguard forever (which is risky as tzdb isn't promising forever) I'm simply suggesting an alternative proposal that would IMO be better than these two options. Another alternative would be to express both pieces of information in the data somehow - whether the period is summer or winter and the legal status of whether that is referred to as standard or daylight. eg. Eire would have values of DST-Winter and Std-Summer, whereas most places would have Std-Winter and DST-Summer. That way a parser could choose to read either the DST/Std value or the Summer/Winter value and proceed accordingly. Finally I'll note that *both* views of the data are sensible and reasonable: - offset-focus: base/standard time in winter, advanced/daylight time in summer (Java's choice and tzdb's old choice) - legal-focus: follow government law as to the meaning of standard/daylight (tzdb's new choice) Most Java libraries aren't going to change because doing so would impact compatibility in APIs.The real problem here is how tricky it is to reverse engineer the old data from the new data. Stephen