[tz] Java & Rearguard

[Stephen Colebourne]

On Wed, 29 May 2019 at 18:05, Paul Eggert <eggert at 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