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

[Andrew Leonard]

So the tool we have at the moment basically supports producing a 
"rearguard" format only at the moment for the reasons you elude to, and as 
such when searching it distinguishes from a jdk8 install and a jdk11+ 
install on that basis. This means to support the IANA vanguard extensions 
work would be needed to support that. Since it currently only produces 
rearguard, then it does not need to distinguish between a jdk11,13,...
It raises questions as to whether the tool should determine the jdk 
"vendor", and perhaps be "vendor" specific, but then we get into the 
discussion well ok this is a vendor tool the, like Oracle, Azul,... 
already have. Can a generic "OpenJDK" solution work, as individual vendors 
might have bespoke timezone differences? but presumably a Oracle JavaSE 
customer will use the Oracle tzupdater and not this...

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




From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Severin Gehwolf <sgehwolf at redhat.com>, Andrew Leonard 
<andrew_m_leonard at uk.ibm.com>, jdk-dev at openjdk.java.net
Date:   25/11/2019 11:25
Subject:        [EXTERNAL] Re: TimeZone Updater Tool/Project, where would 
we put it?



On 25/11/2019 10:24, Severin Gehwolf wrote:
> Hi,
>
> On Mon, 2019-11-25 at 10:02 +0000, Andrew Leonard wrote:
>> Hi there,
>> Not had a lot of interest in contributing this yet, so was going to ask
>> the question a different way. If we were to contribute it where would 
we
>> put it?
>> - As part of the JDK project?
> IMHO yes. Consider making it built-time enable-able via configure
> switches (e.g. --with-tz-updater={yes,no})
>
I found Andrew's original mail where he described it as GUI or CLI tool 
that scans the file system for run-time images. I assume it must have 
knowledge of each JDK release as the format of the TZ data has changed 
in recent years. There isn't enough info to know if it looks at the 
`release` file and skips/rejects releases that it doesn't know about.  I 
guess my point is that I wouldn't expect to run 
`jdk-11.0.1/bin/tzupdate` to update the jdk-13.0.1 on my system. On the 
other hand, I could imagine a tzupdate tool in the JDK that is capable 
of updating the TZ data in its own run-time image. If the interface to 
that tool is stable then the scan-the-world tool could find it and 
invoke it. There are several other approaches, probably needs a write-up 
of the options to see what is the most workable.

-Alan




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