TZUpdater for JDK 7 available (again)

The Timezone Updater Tool (aka TZUpdater) is available for public download from OTN [1] again.

On March 8, 2013, as part of maintenance tied to the end of public updates for Oracle JDK 6, the "Timezone Updater Tool" [2] was removed from OTN, with just a short note that this tool was now only available for Oracle Java SE Support customers. An unintentional side effect of this change was that it became impossible to keep Oracle JDK 7 up to date without a support contract, which is not in line with our policy: The most recent version of the Oracle JDK will always be available royalty free (including any tools required to keep it up to date).

The function of the TZUpdater tool is to enable an Oracle JDK or JRE user to patch their installation with the most recent timezone data. Our goal is to make sure that the most recent version of the JDK and JRE always contain the most recent timezone data, so that there is rarely need for a separate TZUpdater tool - you just upgrade to the most recent JDK/JRE. However, this is not always possible given the timing of the timezone updates and has specifically not been true over the past several months. We are reviewing our development process to determine what guarantees we can put in place for the gap between a timezone update and it being available in a public JDK/JRE release, and will also continue to make TZUpdater available for the most recent JDK version whenever it is needed to keep the most current JDK/JRE up to date.

For users who require updates and supportability tools for older versions of the Oracle JDK, we continue to recommended Java SE Support [3] which provides long term support.

To all of those in the Java community who were affected by this, we apologize for any confusion or inconvenience we caused, and we are grateful to those of you who reached out to us directly to bring this to our attention. As always, several Java User Group leaders and Java Champions were diligent and helpful - Stephen Colebourne, in particular, provided detailed, helpful technical analysis from a community perspective.

[1] -
[2] -
[3] -


Thought: rather than having tzupdater updated for each new timezone data update, maybe having it able to simply download a specified version from the IANA site and compile and install that? That way maintenance should become a non-issue.

I played with the javazic code and it seems to be straightforward, the only issue besides a bunch of warnings about unused variables and imports is an exception parsing the Europe/Moscow entry that I haven't taken the time to track down.

Posted by Todd Knarr on June 10, 2013 at 01:53 PM PDT #

Just wanted to say Thank You for reacting quickly and re-enabling the updater. This will be appreciated by developers across the globe.

Posted by Stephen Colebourne on June 10, 2013 at 03:07 PM PDT #

So, just to clarify:

* The TZUpdater tool wil only work on the most recent JDK/JRE releases - it won't necessarily work on older point releases?
* The TZUpdater tool will only be available when there is are tz updates that aren't bundled into the most recent JDK/JRE release

Is that correct?

Posted by Robert Watkins on June 11, 2013 at 12:17 AM PDT #

Thanks Henrik and Donald

Posted by Richard Kolb on June 11, 2013 at 12:31 AM PDT #

Todd - Our enterprise customers (in general) want predictability and control above all. We are looking at other options for future changes to how timezones are handled, including something similar to your suggestion.

Posted by Henrik on June 11, 2013 at 08:37 AM PDT #

Robert - We do expect users of the free Oracle JDK to stay up to date to get access to patches and fixes, and that includes timezone data. It's the only realistic way to scale the "business" of providing a free download. As I stated in the blog post, we will look into what SLA we can provide and update our product pages on OTN ( accordingly. But *at minimum* we will guarantee that you can always keep up to date with the latest timezone data through either (a) installing the most recent publicly available JRE/JDK or (b) installing the most recent JRE/JDK and then patching it with a publicly available TZUpdater tool. If you want a *guarantee* that you will be able to patch/update older JDK/JRE releases, primarily referring to JDK 5/6, but possibly old JDK 7 updates as well, you will need a support contract. The rationale here is that we can't predict the future - we need to be able to change the implementation for instance. I hope this makes sense.

Posted by Henrik on June 11, 2013 at 08:46 AM PDT #

It makes complete sense, and I agree with the reasoning - I just wanted to make sure there was no ambiguity in the statement.

Posted by Robert Watkins on June 11, 2013 at 01:56 PM PDT #

Henrik: I think it's not only enterprise customers that need the updates. As an individual I can't afford the cost of a support contract, but due to software I need to use for work I have to maintain older versions of Java (as far back as 1.5) and they need updated for current timezone changes. Using Java 7 is impossible because, as enterprise software, the stuff's coded and configured to prevent it running on any JRE it wasn't certified for. What I've coded now works off a downloaded archive and automates the unpacking, compiling and installation. Having it download based on a version identifier will be fairly straightforward. Downloading via the -latest link and parsing out the version would be the part non-admins would want though.

Posted by Todd Knarr on June 18, 2013 at 01:26 AM PDT #

Hi Todd - We fund the development of Java by selling long-term support ($5 per desktop per year iirc) and requiring a commercial license for embedded use (starting at $0.60 per processor for a perpetual license). Due to the low price we don't currently have a good way to scale it to individual consumers, but the model should work for any business except possible the very smallest ones. For individuals and others of restricted financial means, we provide a gratis Oracle JDK 7 and we also contribute most of our work to OpenJDK for those who want to roll their own, as you do. Just make sure you stay within the bounds of the license (GPLv2 and/or BCL depending on your solution) and trademark requirements (eg, don't use the name "Java" as part of your web site or download). Apart from those, this type of community effort is exactly what we intend to make possible with OpenJDK.

Posted by Henrik on June 18, 2013 at 08:02 AM PDT #

It makes complete sense, and I agree with the reasoning - I just wanted to make sure there was no ambiguity in the statement.

Posted by A.MURUGESAN on June 27, 2013 at 06:58 PM PDT #

Post a Comment:
Comments are closed for this entry.

Henrik Stahl is VP of Product Management in the Java Platform Group at Oracle, and is responsible for product strategy for Java ME and SE.


« April 2014