<i18n dev> Using system tzdata

[Masayoshi Okutsu]

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 <Masayoshi.Okutsu at ...> 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
>
>