TimeZone Updater Tool/Project, where would we put it? (original) (raw)

Andrew Leonard andrew_m_leonard at uk.ibm.com
Tue Nov 26 14:06:03 UTC 2019

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

More information about the jdk-dev mailing list