JDK-6224672 : Fix for escalation 1-3216881 broken for time zone issue with date on windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.3.1_13
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-02-02
  • Updated: 2011-02-16
  • Resolved: 2005-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.1_17 b01Fixed
Related Reports
Relates :  
Relates :  
Description
The fix for bug 5088889 and escalation 1-3216881 introduces a new issue.

This issue is only reproducible with 1.3.1_xx , its fixed in 1.4.2 or 1.5.0

Attached is the simple test case.

Before running the test, change the system time settings as follows.
Change the Date to April 4, 2004 and time to 1:58:00 AM ( This is 2 min before we switched over to daylight savings time this year) Set the timezone to Pacific , but UNCHECK the "Automatically adjust clock for daylight savings changes". (as in the attached picture). This is important to reproduce the problem.

Run the attached class.
Now, let the system time change to 2:00am on April 4, then run the test class again. You will see that the system time shows 2:00am, while the test class output shows 3:00am.

It seems that if in the system time setting, you select a timezone that has the checkbox to adjust for daylight savings, the jvm does not recognize the fact that this box is unchecked. Timezones such as Arizona and Indiana which do not even display this checkbox (and do not change for daylight savings) work fine.

Now try to reproduce it with the fix for 1-3216881 . The time zone change issue is taken care off, but the test program now outputs the date in GMT (??) format instead of the correct time zone.

According to Rob Mckenna
"Hi Manish,

Development see this problem as a separate issue. As far as they are concerned this has been fixed and the difference in timezone names is another problem altogether. We need to open a separate CR to work on this issue. Please file it as soon as you get the chance. We will also need a new escalation (sorry about this) id in order to putback the fix from this new CR...

   -Rob "

###@###.### 2005-2-02 18:16:07 GMT

Comments
EVALUATION Could the submitter provide the following information? - What does "in the GMT (??) format" mean in Description? - What is the exact release number of 1.3.1_xx that has the 4296930 fix back port? (I ran test/java/util/TimeZone/DisableDSTTest.java on 1.3.1_11 and 1.3.1_15. Both failed.) - What's the exact time zone setting on the Windows system? - What does the following code produce? System.out.println(TimeZone.getDefault()); ###@###.### 2005-2-03 06:31:42 GMT Additional question. - What's the exact locale setting of the machine? ###@###.### 2005-2-10 05:25:47 GMT This CR claims that 5088889 was fixed under escalation 1-3216881. However, 5088889 was closed as a duplicate of 4296930, and I don't see any sub CR for the 1.3.1_xx fix under either 4296930 or 5088889. What's the sub CR number of the 4296930 (or 5088889) fix for 1.3.1_xx? ###@###.### 2005-2-10 05:41:53 GMT
03-02-2005