JDK-4832236 : REGRESSION: (new Date(0L)).toString() == "Thu Jan 01 01:00:00 GMT 1970"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.1
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-03-13
  • Updated: 2003-03-14
  • Resolved: 2003-03-14
Related Reports
Duplicate :  
Relates :  
Relates :  
Description

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) 
======================================================================

Comments
EVALUATION According to the Olson public source, the GMT offset from 1968-10-27 to 1971-10-31 was one hour. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 0:00 EU GMT/BST See also http://student.cusu.cam.ac.uk/~jsm28/british-time/ which explains the history of legal time in Britian. It says, "and the experiment with British Standard Time from 1968 to 1972, by which the time was advanced by one hour from GMT throughout the year." The local time produced by Date.toString() is historically correct, except for the time zone abbreviation. It should be "BST" (British Standard Time for this case), but it's a known limitation of the current TimeZone implementation. I'm closing this bug as a duplicate of 4255109. If this historical correctness is rather undesired, specify the "GMT" time zone. ###@###.### 2003-03-14 I realized that the Windows platform has only one time zone for Dublin, Lisbon and London, while these time zones aren't historically the same. If you need the historically correct Lisbon time zone, -Duser.timezone=Europe/Lisbon can be specified to make Europe/Lisbon the default time zone. The time zone data for Lisbon is as follows. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Lisbon -0:36:32 - LMT 1884 -0:36:32 - LMT 1911 May 24 # Lisbon Mean Time 0:00 Port WE%sT 1966 Apr 3 2:00 1:00 - CET 1976 Sep 26 1:00 0:00 Port WE%sT 1983 Sep 25 1:00s 0:00 W-Eur WE%sT 1992 Sep 27 1:00s 1:00 EU CE%sT 1996 Mar 31 1:00u 0:00 EU WE%sT The GMT offset is still one hour from 1966-4-3 to 1976-9-26, though. ###@###.### 2003-03-14
14-03-2003