Olson time zone data tzdata2005r or greater incompatibility

---

Impact

JREs or JDKs containing Olson time zone data, version 2005r or greater, are subject to two issues with the Eastern, Mountain and Hawaiian time zones.

As a result, daylight savings time is calculated incorrectly for these time zones under certain circumstances.

For more background see: Background Overview on Sun Alert Doc : 102836 http://java.sun.com/developer/technicalArticles/Intl/alertFurtherInfo.html

1.1 Scope

You are affected if:

• You use the three letter time zone IDs "EST", "HST", "MST" instead of the long format, e.g., "America/New_York".

AND/OR

• You parse time strings that contain "EDT", "HDT", "MDT"

 

You are not affected in the following cases:

• If you are using releases Java SE v1.3.x and below.

OR:

• When processing "HST" and "HDT" Hawaiian dates before 1947.

1.2 Problem Statement

Two distinct, but related issues exist.

The first problem is described by Sun bug 6466476.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6466476

This issue is an incompatibility in the definition of time zone objects identified by the time zone IDs "EST", "MST" or "HST". Prior to Olson data 2005r these 3 IDs refer to zones which observe daylight savings time. For Olson data 2005r or later these 3 IDs refer to zones which do not observe daylight savings time.

The second is described by Sun bug 6530336.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6530336

It effects the parsing of date strings containing the strings "EDT", "HDT" or "MDT", for example "July 4th 2007, 1:00 pm EDT".

Contributing Factors

Both issues occur in JREs containing Olson time zone data 2005r or later.

These are:

• JDK and JRE v1.4.2_12 and above
• JDK and JRE 5.0u8 and above
• JDK and JRE 6 and above
• Any JDK and JRE where Time Zone Updater Tool for v1.4.x+ has been run without the "-bc" flag

Symptoms

In the above conditions DST will be calculated incorrectly.

Workaround

Apply the resolution detailed in section 5, if you are exposed or in doubt.

Resolution

5.1 To effect the correction:

(ie. to enable support for the backward compatible DST time zones):

Run Time Zone Updater Tool for v1.4.x+ with the command line options:

    -f -bc

If you have already run without the -bc flag, you will still need to rerun with the -f -bc flag to correctly resolve the 3-letter time zone abbreviation issue.

Note: A side effect of running TZ Update Tool with -f -bc on the following:

• JDK and JRE v1.4.2_12 and above
• JDK and JRE 5.0u8 and above
• JDK and JRE 6 and above

is that the definition for the deprecated IDs: "EST", "HST", "MST" will revert to the pre 2005r definition which is to observe daylight savings time. A fix is not yet available, Sun does not expect this to be an issue for most applications since the time zones IDs were deprecated in 1998.

Note: An alternative to the TZ Updater Tool is to manually remove:

• JAVAHOME/jre/lib/zi/EST
• JAVAHOME/jre/lib/zi/MST
• JAVAHOME/jre/lib/zi/HST

These two operations are equivalent in that they correct for the time zone ID incompatibility issue.

Other related notes:

Q. If I'm using the deprecated time zone IDs: "EST", "HST", "MST" and I am running JRE versions:

• JDK and JRE v1.4.2_12 and above
• JDK and JRE 5.0u8 and above
• JDK and JRE 6 and above

should I apply the resolution?

A. You must decide between fixing the parse problem, bug 6530336, problem or maintaining the "EST", "HST", and "MST" semantics of those releases. If you apply the resolution, you will change the sematics of "EST", "HST", and "MST" IDs to observe daylight savings time.

Q. Does this issue affect Solaris, Linux, and Windows?

A. This issue affects all platforms.

Q. Do affected Java applications have to be stopped before running TZ Updat Tool?

A. Since the JVM contains SoftReferences to TimeZone specific objects, the safest action is to stop the JVM before updating. The consequences of not stopping the jvm could be that old cached copies of TimeZone objects remain in the jvm operating environment.

Q. Are packages within Solaris affected ?

A. Packages within Solaris should not have any hard-coded time zone specific time stamps. Most Solaris applications using Java will read their time zone from the local OS environment, i.e the environment variable "TZ". No "TZ" variable should be using a three letter timezone ID, in particular the conflicting three letter IDs mentioned in this Sun Alert. As a result, these packages should not suffer from this compatibility issue.

Q. I get the following message after running the TZ Updater Tool v1.1.0 on Solaris, what does it mean?

    <JAVA_HOME>/jre/bin/java not directly found in contents file,
    no package resolution performed. (May not be in PKG form, not
    an absolute path, or is a symlink.)

A. This message indicates that the JDK/JRE just updated was not part of a Solaris package. No step had to be taken to update the OS with the fact that files under package management have changed, i.e jre/lib/zi directory contents. The update of the timezone data has been successful in this case.

For more information:

Time Zone Updater Tool for v1.4.x+ README Information http://java.sun.com/javase/tzupdater_README.html

US Daylight Savings Time Changes and the Java SE Platform: FAQ http://java.sun.com/developer/technicalArticles/Intl/USDST_Faq.html

5.2) Install Issues:

In the unlikely event of unforeseen issues (e.g: such as power loss or IO Error) restore the JRE Time Zone files to their original state by:

a) following the instructions at http://java.sun.com/javase/tzupdater_README.html#remove

OR:

b) removing and then reinstalling the JRE or JDK.

The update may now be re-applied by following step 5.1.

Modification History


Date: 10-MAR-2007

10-Mar-2007:

• All document sections updated

Date: 10-MAR-2007

10-Mar-2007:

• Revision to clarify impact and other customer feedback

Attachments

This solution has no attachment