JDK-4459694 : Rolling times during a DST transition is incorrect
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-05-16
  • Updated: 2001-07-05
  • Resolved: 2001-07-05
Related Reports
Duplicate :  
Description

Name: bsC130419			Date: 05/16/2001


$ java -version
java version "1.3.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_02)
Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)


Calling Calendar.add for sub-hour fields, during the first occurence of the
doubled time during a daylight-savings-time transition, yields the incorrect
resulting time, if the time fields are recalculated.

Sample source code:

import java.util.*;
import java.text.*;

public class TestDST {
  public static void main(String[] argv) {
    DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL,
                                                   DateFormat.FULL);
    df.setTimeZone(TimeZone.getTimeZone("America/New_York"));

    Calendar now =
      new GregorianCalendar(TimeZone.getTimeZone("America/New_York"));

    now.setTime(new Date(877843800000L));
    // Sunday, October 26, 1997 1:30:00 AM EDT

    System.out.println(df.format(now.getTime()));
    System.out.println(now.getTime().getTime());

    now.clear(Calendar.WEEK_OF_YEAR); // force fields to be cleared

    now.add(Calendar.SECOND, -1);

    System.out.println(df.format(now.getTime()));
    System.out.println(now.getTime().getTime());
  }
}

Observed output:
$ java TestDST
Sunday, October 26, 1997 1:30:00 AM EDT
877843800000
Sunday, October 26, 1997 1:29:59 AM EST
877847399000

Expected output:
Sunday, October 26, 1997 1:30:00 AM EDT
877843800000
Sunday, October 26, 1997 1:29:59 AM EDT
877843799000
(Review ID: 124505) 
======================================================================

Comments
WORK AROUND Name: bsC130419 Date: 05/16/2001 grandcentral $ java TestDST If a calendar might be in a DST transition, don't do anything that might set fields invalid? I'm not sure how practical this is. This directly conflicts with a workaround for another bug I just submitted (no bugID yet -- search for setMinimalDaysInFirstWeek). ======================================================================
11-06-2004

EVALUATION When computing time from the calendar fields, GregorianCalendar assumes that the fields represent standard time during the DST transitions. This causes a probrem if the given date exists twice in a standard time and in a daylight standard time like this bug's case. Because "October 26, 1997 1:30:00 AM EDT" is changed into "October 26, 1997 1:30:00 AM EST" after recalculation. To handle such transition between a standard time and daylight saving time correctly, it is necessary to have a flag that indicates what time (wall time/standard time/daylight saving time) is used. Since RFE#4312621 includes this problem, this bug is closed as a duplicate bug. yuka.kamiya@japan 2001-07-05
05-07-2001