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

Andrew Leonard andrew_m_leonard at uk.ibm.com
Mon Dec 2 14:33:13 UTC 2019

Hi Sean,
Yes, I can see where you're going, it does seem more structured to define 
an upgradeable module method... has anyone had a go at producing a 
build/make mechanism to build one of those from the latest IANA data?
Could we modularise the current TzdbZoneRuleProvider into it's own module, 
and then allow a openjdk make target to build just that with the latest 
IANA and produce a upgradeable module replacement image for it...?

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

From:   "Seán Coffey" <sean.coffey at oracle.com>
To:     Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com>
Cc:     jdk-dev <jdk-dev at openjdk.java.net>
Date:   02/12/2019 12:55
Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would 
we put it?

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.



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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

More information about the jdk-dev mailing list