[threeten-dev] TzdbZoneRulesCompiler

[Stephen Colebourne]

On 14 December 2012 20:44, Xueming Shen <xueming.shen at oracle.com> wrote:
> This is the first draft to pull the tzdb compiler out of the core
> javax.time.zone
> package. "Inevitably" it brings the ZoneRulesBulder with it and then the
> StandardZoneRules and finally the Ser:-)

I would expect the ZoneRulesBuilder to be separated as well, as it is
designed in quite a TZDB way.

> Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely outsource
> its serialization to the Ser. Arguably, it should be fine to just leave the
> serialization
> stuff of these two classes to the default implementation, or further, not
> serializable
> at all (any third-party ZoneRules implementation, if any, can feel free to
> implement
> their serialization form for these two, if they are needed in their
> ZoneRules serialization
> form...). The implementation will be clearer, if we give up the
> serialization of these
> two classes. We still keep those read/write of these two for SZR.

There is no need for ZOT and ZOTR to be independently serializable.
Only the rules themselves need to be serializable.

> There are still 2 issues in ZoneOffsetTransition class. The big one is that
> it appears
> we have bunch of "transitions" that have the same before and after offset
> from the
> builder/compiler, I have not looked into the details of these "transitions".

They are probably due to locations where the time-zone name changed
without changing the offset.

> The small one is that the toEpochSecond() method,
> which is
> "frequently" used by the builder and the SZR, is it worth make it public, or
> I should have
> it as the utility method somewhere in sun.time.zone.

There is a case for ZoneRules to have a getOffset(epochSecond) method
as well. If the method has to be public then so be it.

> Opinion?  the surgery is too big?

Taking a step back, I think that ZoneRules probably does not need to
be an interface. There are only two sensible implementations - single
offset and complex, as per StandardZoneRules.

If we made this change, then StandardZoneRules and the rules inside
ZoneOffset would merge inside ZoneRules. Then, all the serialization
would stay in the core. The tool would simply create the necessary
items to pass to the standard public factory on ZoneRules.

So, what you've done makes sense given where we are, but I think there
is a better option.

Stephen