As noted on a recent /. and TSS thread, some have noticed that a tool known as the Java SE Time Zone Updater (aka “TZUpdater”) is no longer publicly available. There seems to be some misunderstanding about the purpose of the tool and the impact it’s non-public availability will have.
You do not require the TZUpdater in order to have correct timezone information in your Oracle Java SE applications – it comes automatically with every version and gratis update of Oracle Java SE.
Oracle Java SE 6 is now well past end of public updates. Users are always encouraged to update to the latest gratis public releases available. Users who choose to run older and not publicly supported versions, wanting updates and tools such as the tzupdater for these old, not publicly supported versions, can consider commercial long term support options.
– Don
DonaldOJDK Blog 
There is probable some missunderstanding here, Sometimes you can’t wait until the next update to receive the new timezone database. When my country, Venezuela, had a timezone change, Sun at that time did exactly what is happening now, the updater was only for support contracts and the next update was very far away from the tz change date. I resorted to compile my own database from sources because Sun left an entire country without the update when needed
Hi Robert, thanks for the comment. Let me look into this and respond with more details later. Quickly for now – I understand your comment that this happened to you with an early 6u, but there’s some assumptions around future updates that have changed and I don’t believe this will be a significant issue hereon — but let me get back to you when I can with specifics.
I’m not clear that you’ve addressed the issue of someone using JDK7 who needs an immediate time-zone update. Local authorities change their time-zone rules in completely arbitrary ways and on arbitrary schedules. It is far from uncommon for there to be just a few days notice of a time-zone change, and even the TZDB database struggles to release often enough. As such, there is no way that the answer “wait until the next Oracle JDK7 release” is a viable choice.
What about those using JDK7? That isn’t EOL. And users still need to be able to update their time-zone data faster than Oracle releases new updates. (Time-zone rules can be changed with just a few hours notice in some parts of the world). This decision (a) looks cheap and (b) isn’t thought through.
Hi Stephen, yes – this is exactly what Robert is noting, and as I said I wouldn’t want to minimize that as being obscure, so as I said, there’s some additional information required here and I’ll update the specifics when I can.
FYI — As per Henrik’s blog [1], the TZUpdater tool will be made available, likely by EOB pacific today (June 10, 2013). Much thanks to all who provided constructive feedback and apologies for any inconvenience.
– Don
[1] – https://blogs.oracle.com/henrik/entry/tzupdater_for_jdk_7_available
What I’d like is a tzupdater tool that I could give the version number of the latest update to and have it download the update from IANA and install it. javazic’s there, and that’s the heart of it.
What about Java 8 and the 3 1/2 Date/Time APIs it’s coming with? Are all maintainable by the same TZUpdater or will there be a new tool, hopefully covering ALL of these APIs, not just some of them? (especially java.util.Date/Timezone and the replicated functionality in java.time)
While since Java 7 the Currency class has a more or less documented override mechanism for currency data (e.g. if a country leaves the Euro-zone or enters it before a new JDK comes out;-), some improvement in this area compatible with the Java 7/8 approach seems in the interest of what people both in the community and JCP EC (in Zurich) said, they would like to see for JSR 354 following its EDR. If the i18n team at OpenJDK is open to help and discussion the JSR 354 EG and Spec Lead are more than happy to speak to them about it.
Werner
Most recent publicly supported versions will always have some way to keep current.