Thank you for asking! :-) Here's the whole history on the time zone data
maintenance.
From 1.1 to 1.3.1, time zone data was hard-coded in
src/share/classes/java/util/TimeZone.java which was compiled into
rt.jar. Also it was java.util.SimpleTimeZone-based, which made it
difficult to deal with real world time zone changes, such as GMT offset
changes. The date-time API came from Taligent OS, except for
java.util.Date, along with many other i18n classes (e.g., java.text). We
(java i18n team) took over the date-time API responsibility as of 1.4.0
development from Taligent, which later became IBM.
In 1.4.0, the whole time zone support was reimplemented so that real
world time zone changes, including past and future changes, could be
supported. We used the public zoneinfo data (a.k.a. Olson tzdata). One
of the reasons of the reimplementation was to make it easier to maintain
time zone data. Time zone data was no longer hard-coded, of course. A
Java version of zic (zoneinfo compiler), called 'javazic' internally,
was written to generate necessary information to support the
java.util.Calendar and java.util.TimeZone classes. (At that time we
decided to minimize date-time API changes because we recognized the API
had many problems and that a new API would be required to fix those
problems. Unfortunately, a new date-time API project proposal for 5.0
development wasn't approved. So we had to change our plans deal with the
date-time API problems.)
Time zone support was much improved in 1.4.0. However, the time zone
data maintenance was still an issue. We (java i18n) proposed a couple of
times to open up javazic so that users could update time zone data files
with a new Olson tzdata release. However, at that point, time zone data
maintenance wasn't considered a big problem, and our proposal wasn't
approved. Actually nobody else paid much attention to the issue.
Before long the world was changing. Many countries were changing their
daylight saving time rules and GMT offsets to deal with the energy
crisis. Olson tzdata was frequently updated. It wasn't quick enough to
just add the latest Olson tzdata to JRE/JDK update releases. Then, the
United States of America announced the DST rule change from 2007, which
completely changed the situation. We had to develop a way to update
tzdata for all existing JRE/JDK installations, including 1.3.1_xx. The
tzupdater tool (http://java.sun.com/javase/tzupdater_README.html) was
developed late 2006. (Actually there are two versions; one for 1.4+
which updates tzdata files in <JRE>/lib/zi, and the other for 1.3.1_xx
which updates rt.jar.)
Tzupdate (for 1.4+) worked. But we encountered a platform specific
problem with Solaris Zones. A workaround was added to the tool. But I
considered it as a temporary solution and proposed migration to platform
specific patch mechanisms to avoid software package maintenance
problems. We may encounter similar problems on other platforms. The
change proposal from Red Hat is related to this issue. That is, the
up2date utility on Red Hat systems should be able to be used to update
the tzdata files for the Java runtime. The meeting I referenced in my
previous message was to discuss my proposal for the migration.
Thank you for listening! So... what should be the best way to maintain
tzdata for Java SE installations?
Thanks,
Masayoshi
On 1/26/2008 12:46 AM, Dalibor Topic wrote:
Masayoshi Okutsu <[EMAIL PROTECTED]> writes:
Sorry again for taking time. Finally, I talked to some sustaining team
members in Ireland to make a decision on the long-term tzdata
maintenance issue. We've determined [...]
Hi,
I've tried to find that discussion in the mailing list archives, but I couldn't
find it. Could you point me to it, or, in case it was not on this list, post it
for your fellow OpenJDK developers to read?
thank you in advance,
dalibor topic
