TimeZone Updater Tool/Project, where would we put it?

[Ben Evans]

Hi Seán,

>From my perspective, I agree that this seems like a superior
technical solution. However, I am concerned about how quickly that solution
could be made available.

In the case of Brazil's change - it made it into the timezone data in 2018,
but the JDK only picked it up in October 2019. Depending on the criticality
of a service, that's not a huge window for changing your runtime. We had
already started to experience issues regarding the change before 8u232 was
available.

If IBM have a tool that is close to being usable today, then in my opinion,
it would be far better to get it out there now (perhaps as part of Adopt
rather than upstream if that's easier for you). It can then be replaced by
a cleaner (modular) solution at a more leisurely pace.

In terms of how we'd use it - once available we'd run this tool as part of
our Docker base image builds. While that makes it still possible for an
infrequently changing service to get out of date, it's far less likely and
the fix is just a rebuild away. Other organisations will have other
requirements, of course, but this is an obvious quick-and-dirty solution
that will work for a large number of people.

Just my 2c, of course.

Thanks,

Ben




On Mon, Dec 2, 2019 at 1:57 PM Seán Coffey <sean.coffey at oracle.com> wrote:

> I think Alan and Stephen Colebourne's comment may be on the right track
> for this proposal.
>
> The current tzupdater process is due an upgrade in how it operates.
> We've also considered open sourcing a similar version of our tzupdater
> tool but felt that it needs to be modernized. We should move away from
> updating specific internals (like the tzdb.dat file which is not part or
> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
> to control the location of tzdb.dat were raised [1]
>
> Moving to a service provider and/or upgradeable module solution may be a
> good approach. At the moment,  JDK 8+ uses the
> java.time.zone.ZoneRulesProvider class as the default service provider.
> It can be substituted with use of the
> `java.time.zone.DefaultZoneRulesProvider' system property.
>
> [1]
>
> https://bugs.openjdk.java.net/browse/JDK-8153044?focusedCommentId=13970444&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13970444
>
> Regards,
> Sean.
>
> On 02/12/19 09:23, Alan Bateman wrote:
> > On 29/11/2019 15:08, Andrew Leonard wrote:
> >> The .zip contains the tzupdater "program" along with the latest
> >> tzdb.dat.
> >> The user then unzips this and runs the "program" in the desired "mode".
> >> Currently, it distinguishes jdk8 from jdk11+ only, and the only
> >> version update is that contained within the new tzdb.dat eg."2019c".
> >> So you can run the tool in "discovery" mode which will simply print
> >> out what tzdb version each JDK is at...
> >> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
> >> upon the fact that it's currently producing a "rearguard" tzdb.dat
> >> which is compatible with all these versions... This would need
> >> changing going forward when vanguard is used, and perhaps with that
> >> in sight it maybe best to update the tool to only patch the same
> >> versions from which the updater was built from...
> >>
> >> I can thus see several improvements being discussed here:
> >> - Better JDK version detection
> >> - Possibly provide release/version file update somewhere to identify
> >> the update other than just in the tzdb.dat
> >> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
> >> only patch a jdk13 JDK.
> > I assume "program" means something platform specific or maybe you mean
> > a script?
> >
> > You haven't mentioned it yet but I assume it needs to update more than
> > just tzdb. For JDK 9+ at least, it will need to update the TZ data in
> > the packaged module (java.base.jmod) so that any replication with
> > jlink will use the new TZ data too.
> >
> > There are lots of other questions but it might be better if you
> > started a document to capture the needs, issues, and the possible
> > technical approaches. That should help the discussion and help to see
> > whether it make sense or not for something like this to be part of the
> > JDK build or a separate patching tool.
> >
> > -Alan
>
>