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

Seán Coffey sean.coffey at oracle.com
Mon Dec 2 12:55:06 UTC 2019


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



More information about the jdk-dev mailing list