Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4832236

REGRESSION: (new Date(0L)).toString() == "Thu Jan 01 01:00:00 GMT 1970"

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P2 P2
    • None
    • 1.4.1
    • core-libs



      Name: nt126004 Date: 03/13/2003


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

      FULL OPERATING SYSTEM VERSION :
      Microsoft Windows 2000 [Version 5.00.2195]

      ADDITIONAL OPERATING SYSTEMS :
      All


      A DESCRIPTION OF THE PROBLEM :
      I'm working in Lisbon, Portugal and I've come to this
      problem:

      System.out.println("Date(" + 0L + ") = " + new Date(0L));

      The obtained result was:

      Date(0) = Thu Jan 01 01:00:00 GMT 1970
                           --

      I found out that doing increments on the millisecond value
      I would always get Date.toString and Date.parse to return
      always one hour later until the date 1972/10/31 at 2:59.
      After that time, the Date returns a correct value.

      This only happened when the Locale was set to GMT.

      The problem is with the definition of the TimeZone:

      TimeZone = sun.util.calendar.ZoneInfo
      [id="Europe/London",offset=0,dstSavings=3600000,useDaylight=
      true,transitions=242,lastRule=java.util.SimpleTimeZone
      [id=Europe/London,offset=0,dstSavings=3600000,useDaylight=tr
      ue,startYear=0,startMode=2,startMonth=2,startDay=-
      1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode
      =2,endMonth=9,endDay=-
      1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]


      EXPECTED VERSUS ACTUAL BEHAVIOR :
      Expected:
      Date(0) = Thu Jan 01 00:00:00 GMT 1970

      Actual Result:
      Date(0) = Thu Jan 01 01:00:00 GMT 1970


      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      Using the TimeZone for Portugal:

      TimeZone = sun.util.calendar.ZoneInfo
      [id="Europe/London",offset=0,dstSavings=3600000,useDaylight=true,transitions=242
      ,lastRule=java.util.SimpleTimeZone
      [id=Europe/London,offset=0,dstSavings=3600000,useDaylight=true,startYear=0,start
      Mode=2,startMonth=2,startDay=-
      1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay
      =-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]

      import java.util.*;
      public class Test {
      public static void main(String[] args) {
      System.out.println("Date(" + 0L + ") = " + new Date(0L));
      }
      }

      Or

      import java.util.*;
      public class Test2 {
      public static void main(String[] args) {
      for (long k = 0L; k < 1000L * 60L * 60L * 24L * 365L * 40L; k += 1000L * 60L *
      60L * 24L * 365L) {
        System.out.println("Date(" + k + ") = " + new Date(k));
      }
      }
      }
      ---------- END SOURCE ----------

      CUSTOMER WORKAROUND :
      SimpleTimeZone portugueseTime = new SimpleTimeZone
      (0, "Europe/London" /*GMT / Portuguese Summer Time*/,
      Calendar.MARCH, -1, Calendar.SUNDAY, 1, Calendar.OCTOBER,
      -1, Calendar.SUNDAY, 1, 1);
      TimeZone.setDefault(portugueseTime);

      Release Regression From : 1.3.1
      The above release value was the last known release where this
      bug was known to work. Since then there has been a regression.

      (Review ID: 181569)
      ======================================================================

            okutsu Masayoshi Okutsu
            nthompsosunw Nathanael Thompson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: