JDK-6609675 : [Fmt-Da] DateFormat.parse() on a timezone changes its calendar's timezone
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.4.2,5.0,5.0u27,6u23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-09-26
  • Updated: 2017-05-16
  • Resolved: 2010-04-30
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.
JDK 7
7 b91Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
DateFormat.parse() has an undocumented side-effect: calling it with a string that contains a timezone, different from one that was explicitly set, will overwrite the DateFormat's internal timezone with that of the string.

Further attempts to use the DateFormat for formatting will use the new timezone.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached test case.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Output of the test should be two identical GMT TimeZones, like:

sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]

ACTUAL -
Output of the test is:

sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=3,startDay=1,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.text.DateFormat;
import java.util.TimeZone;

public class TestDateFormat {
    public static void main( String[] args ) throws Exception {
        DateFormat f = DateFormat.getDateTimeInstance( DateFormat.SHORT,
                DateFormat.FULL );
        f.setTimeZone( TimeZone.getTimeZone( "GMT" ) );
        System.out.println( f.getTimeZone() );
        f.parse( "6/15/05 7:00:00 AM PDT" );
        System.out.println( f.getTimeZone() );
    }
}

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

CUSTOMER SUBMITTED WORKAROUND :
Use separate DateFormats for formatting and parsing.

Comments
EVALUATION The fix is to change the API doc so that the behavior and spec are consistent (as of 1.5.0). The changes are: - The parse methods may overwrite the date-time fields and the TimeZone value of the embedded calendar (DateFormat.calendar). - setTimeZone(TimeZone) sets the embedded calendar's TimeZone to the specified TimeZone. - getTimeZone() returns the TimeZone value in the embedded calendar. - setLenient(boolean) sets the embedded calendar to the specified leniency value. - isLenient() returns the leniency value of the embedded calendar. - setCalendar(Calendar) overwrites any TimeZone and leniency values previously set by the setter methods.
06-10-2010

EVALUATION This is a side effect of the bug fix for 4845901.
27-09-2007