On 13 February 2018 at 23:25, Martin Buchholz <marti...@google.com> wrote: > On Tue, Feb 13, 2018 at 3:02 PM, Stephen Colebourne <scolebou...@joda.org> >> If TZDB insists on continuing with the change, the TZDB compiler in >> OpenJDK will have to be changed. I've managed to make a change (hack) >> to the compiler in Joda-Time, so a solution should be possible to some >> degree in OpenJDK too. >> >> https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af4980846d676ba2 > > I was thinking about how to "reverse the polarity". The advantage of a > source transformation is that the code can be shared among all downstream > tzdata consumers. The advantage of building it into the "compiler" is > defense against the maintainer/user mistake of simply overwriting the tzdata > files.
The approach I used was based on Meno Hochschild's approach. When it binds the set of "Rule" entries to a line in the "Zone", it examines the rules to see if any are negative SAVE values, and does the reversal. The only constraint is that the set of "Rule" entries with the same name cannot contain both positive and negative SAVE values, but I don't think the tzdb encoding of a short name could cope with that anyway. AFAICT, this approach should be applicable to ThreeTen-Backport and OpenJDK. I imagine something similar can be done in ICU4J. Stephen
