Hi Deven,
Sorry for taking time to respond.
This is a known restriction of time zone detection on Windows
currently. There used to be a note on this issue with a workaround
in Java SE release notes, but it seems to be gone some time ago. Is
there any reason that the auto-adjust option needs to be kept turned
off for the time zone?
The fix seems OK for the India Standard Time case. But does the fix
work if a time zone has Dynamic DST and starts observing DST some
time in the future?
Thanks,
Masayoshi
On 5/7/2012 6:23 PM, Deven You wrote:
Hi All,
JDK displays incorrect TimeZone display name when DST (Daylight
Saving Time) is disable in the native Time Zone settings on
Windows XP/2003 platforms and the Time Zone does not support DST.
Steps to re-create the problem
1. In the Windows Date and Time Properties dialog, set the time
zone to one that uses DST (e.g. Greenwich Mean Time).
2. Disable the 'Automatically adjust clock for Daylight Saving
Changes' option.
3. Change the time zone to one that does not use DST (e.g. India
Standard Time - (GMT+5:30) Chennai,Kolkata,Mumbai,New Delhi)
4. Compile and run the testcase[1]
Observed output:
GMT+05:30
Expected output:
India Standard Tim
There is already a sunbug[2] for this problem, which describes the
problem clearly and very detailed. Please refer it for more
detail.
Here is some descriptions from the sunbug:
PROBLEM
---------------------------------
Windows provides an option entitled 'Automatically adjust clock
for Daylight Saving Changes' box in the native time zone settings.
When checked, the clock is automatically adjusted to the daylight
savings time if applicable to that particular timezone.
More importantly, if this box is unchecked, Windows will ignore
any DST timetable in the selected time zone.
Now, the JDK's TimeZone class checks the value of the registry
value that corresponds to this option, and modifies the default
TimeZone's display name accordingly. This is from the evaluation
of CR 4296930, describing the fix made for that CR in JDK 1.4.2:
--------
When the auto-adjustment is turned off, the platform time zone
detection code will create a time zone ID in the "GMT{+|-}hh:mm"
form with which a custom TimeZone customer is created. This is
because some Windows users turn it off due to incorrect Win32 time
zones and choose one based on just the GMT offset. A restriction
is that display names are not supported even it just means to use
standard time of a correct time zone selection for some other
purposes.
--------
This makes sense for time zones that do use DST. However, our
customers have found that if you disable DST in the Windows
options for a time zone that uses it, and then switch to a time
zone that doesn't use DST, the option remains disabled (i.e. the
underlying registry value retains the value that corresponds to
the option being disabled).
Under these circumstances the JDK's TimeZone class changes the
display name to the "GMT{+|-}hh:mm" format, rather than using the
correct name. This is unintuitive, and arguably incorrect.
We believe it would be better to query the time zone to see if DST
is actually applicable before deciding whether or not to switch to
the "GMT{+|-}hh:mm" format.
Note that this issue is not applicable to Windows Vista/7 because
the relevant registry value is reset each time the native time
zone is changed, rather than being retained as it is in Windows
XP/2003.
I have made a fix which will deal with this situation and avoid
the "GMT{+|-}hh:mm" format.
[1]
http://cr.openjdk.java.net/~littlee/ojdk-557/webrev.00/
[2]
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7094176
Thanks a lot!
--
Best Regards,
Deven
|
