JDK-4845901 : SimpleDateFormat.parse(String) is an hour off for Australia EST TZ
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2003-04-09
  • Updated: 2004-02-03
  • Resolved: 2004-02-03
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
5.0 b37Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description

Name: jl125535			Date: 04/09/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Windows TimeZone = "(GMT+10:00) Canberra, Melbourne, Sydney"
Automatically adjust for daylight saving checkbox selected.

A DESCRIPTION OF THE PROBLEM :
When using a SimpleDateFormat with a pattern of "yyyy.MM.dd
G HH:mm:ss.SSS z" to parse a String of format "2003.01.13 AD
11:10:00.802 EST" SimpleDateFormat.parse(String) returns an
incorrect Date.

The Time field is always one hour out.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Set the Windows Timezone to the Sydney Timezone.
2. Ensure the "Automatically adjust for daylight saving"
checkbox is selected.
3. Compile and run provided java source.


EXPECTED VERSUS ACTUAL BEHAVIOR :
What I'm expecting is the returned Date be the same as the
input Date/Time String, as both the input timezone (EST) and
the machines timezone are the some.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Date;
import java.text.SimpleDateFormat;

public class Test {
    public static void main (String args[]) {
        try {
            String attr = "2003.01.13 AD 11:10:00.802 EST";
            System.out.println("attr = " + attr);

            String DATE_TIME_PATTERN = "yyyy.MM.dd G HH:mm:ss.SSS z";
            SimpleDateFormat dfDeptDate = 
                new SimpleDateFormat(DATE_TIME_PATTERN);

            Date parsedDate = dfDeptDate.parse(attr);
            System.out.println("parsedDate = " + parsedDate);

        } catch (Exception e) {
            e.printStackTrace();
        }
        System.out.println("done.");
        System.exit(0);
    }
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
De-selecting the "Automatically adjust for daylight saving"
checkbox on the Windows Timezone dialog.
(Review ID: 179963) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b37 tiger-beta2
14-06-2004

EVALUATION In Australia/Sydney TimeZone, the short TimeZone display name for the daylight saving time is the same as the short TimeZone display name for the standard time. Both of them are "EST". DecimaFormat.parse() interprets "2003.01.13 AD 11:10:00.802 EST" as the standard time, and returns +1 hour to adjust the daylight saving time. The way of parsing TimeZone display name needs to be reviewed. ###@###.### 2003-11-06 The fix is to let a Calendar and TimeZone decide whether it's standard or daylight time. However, it's not possible to perfectly disambiguate the given time. Please use "Z" or the long time zone names ("zzzz") to disambiguate time zone offsets. ###@###.### 2004-04-13
13-04-2004