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

[Deven You]

This is the MSDN reference[1]

[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724253%28v=vs.85%29.aspx

On 05/16/2012 02:09 PM, Deven You wrote:
> 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


-- 
Best Regards,

Deven

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