United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7094176 (tz) Incorrect TimeZone display name when DST not applicable / disabled
JDK-7094176 : (tz) Incorrect TimeZone display name when DST not applicable / disabled

Details
Type:
Bug
Submit Date:
2011-09-23
Status:
Resolved
Updated Date:
2013-06-26
Project Name:
JDK
Resolved Date:
2012-06-12
Component:
core-libs
OS:
windows_xp
Sub-Component:
java.util:i18n
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6u27
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
SYNOPSIS
--------
Incorrect TimeZone display name when DST not applicable / disabled

OPERATING SYSTEM
----------------
Windows XP and Windows 2003
Not applicable to Windows Vista and Windows 7

FULL JDK VERSION
----------------
Java 7 (tested with GA release (b147))
Java 6 (tested with 1.6.0_27)

PROBLEM DESCRIPTION from LICENSEE
---------------------------------
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.

For time zones that never have DST (e.g. India Standard Time), this option disappears from the dialog and cannot be checked/unchecked. This makes sense, as it should make no difference either way.

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 object 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.

TESTCASE
----------------
import java.util.TimeZone;

public class DstTzTest {
    public static void main(String[] args) {
        System.out.println(TimeZone.getDefault().getDisplayName());
    }
}

REPRODUCTION INSTRUCTIONS
------------------------------------------------
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

Observed output:
GMT+05:30

Expected output:
India Standard Time

WORKAROUND
----------
Specify the timezone on the command line. For example: -Duser.timezone=Asia/Kolkata

* See Comments for SUGGESTED FIX from Licensee.

                                    

Comments
EVALUATION

The suggested fix went to JDK 8 b43.
                                     
2012-06-12



Hardware and Software, Engineered to Work Together