<i18n dev> Incorrect TimeZone display name when DST not applicable / disabled

[Deven You]

Hi Masayoshi,

This fix is only for Time zone which does not support DST.

For your first question, the scenario is that when current time zone 
supports DST and the "Automatically adjust clock for Daylight Saving 
Changes" option is unchecked. At that time if people change the timezone 
to one that does not support DST.

On Windows XP, the value of "0x1" will be retained for the registry key 
"DisableAutoDaylightTimeSet" instead of getting reset to "0x0".  I think 
this is a Windows XP limitation.

For the second question, this fix only change the "GMT{+|-}hh:mm" to the 
standard name of a time zone, it is not related to any Time zone which 
supports DST.

Some detail for this fix:

1. On Windows OS like XP/2003, the registry key 
"DisableAutoDaylightTimeSet" (under 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation) 
is used to determine if the auto-daylight time adjustment is turned off 
or not. By default, the value of this registry key will be "0x0". When a 
user turns off the "Automatically adjust clock for Daylight Saving Time" 
on the machine for a time zone that supports DST, then the registry 
value for "DisableAutoDaylightTimeSet" will be set to "0x1". Now when 
the user switches to a time zone that does not support DST, the value of 
"0x1" will be retained for the registry key "DisableAutoDaylightTimeSet" 
instead of getting reset to "0x0". (Note: The "Automatically adjust 
clock for Daylight Saving Time" is not applicable to time zones that 
does not support DST, so the registry key "DisableAutoDaylightTimeSet" 
should always be "0x0".) Hence we see the incorrect output (problem 
reported in defect 184237/184237.70)

2. On Windows Vista or later OS, a different registry key namely 
"DynamicDaylightTimeDisabled" (under 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation) 
is used.
The value of the registry key "DynamicDaylightTimeDisabled" will be set 
to "0x0 by default. It will be set to "0x1" when "Automatically adjust 
clock for Daylight Saving Time" is disabled on the time zone that 
supports DST. When the user switches to a time zone that does not 
support DST, the value of registry key "DynamicDaylightTimeDisabled" 
automatically gets reset to "0x0". So we don't see the problem with 
Windows Vista or later OS.

3. tzi.DaylightDate.wMonth is used to check if a time zone supports DST 
or not. See MSDN[1]:

"If the time zone does not support daylight saving time or if the caller 
needs to disable daylight saving time, the wMonth member in the 
SYSTEMTIME structure must be zero"

This fix use the conjunction of key "DisableAutoDaylightTimeSet" and 
tzi.DaylightDate.wMonth to determine if a time zone dose support DST.

If there is any unclear things please let me know!

Thanks a lot!


On 05/11/2012 11:18 PM, Masayoshi Okutsu wrote:
> 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/ 
>> <http://cr.openjdk.java.net/%7Elittlee/ojdk-557/webrev.00/>
>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7094176
>>
>> Thanks a lot!
>> -- 
>> Best Regards,
>>
>> Deven


-- 
Best Regards,

Deven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120516/b5cc60b7/attachment.html