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
You are affected if:
You are not affected in the following cases:
Two distinct, but related issues exist.
The first is described by Sun bug 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.
It effects the parsing of date strings containing the strings "EDT", "HDT" or "MDT", for example "July 4th 2007, 1:00 pm EDT".
Both issues occur in JREs containing Olson tzdata 2005r or later. These are:
In the above conditions DST will be calculated incorrectly.
Apply the resolution detailed in section 5, if you are exposed or in doubt.
Run Time Zone Updater Tool for v1.4.x+ with the command line options:
Note: A side effect of running TZ Update Tool with -f -bc on the following:
Note:An alternative to the TZ Updater Tool is to manually remove:
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:
A. You must decide between fixing the parse problem, bug 6530336, 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 the tzupdater tool ?
A. Since the JVM software contains SoftReferences to TimeZone specific objects, the safest action is to stop the JVM software before updating. The consequences of not stopping the JVM software could be that old cached copies of TimeZone objects remain in the JVM software's 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, namely, 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 software just updated was not part of a Solaris package. No step was necessary to update the OS with the fact that files under package management have changed, that is,
jre/lib/zi directory contents. The update of the timezone data has been successful in this case.
For more information:
In the unlikely event of unforeseen issues (for example, a power loss or IO Error) restore the JRE Time Zone files to their original state by:
a) following the instructions at: here
b) removing and then reinstalling the JRE or JDK software.
The update may now be re-applied by following step 5.1.