United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4832236 : REGRESSION: (new Date(0L)).toString() == "Thu Jan 01 01:00:00 GMT 1970"

Details
Type:
Bug
Submit Date:
2003-03-13
Status:
Closed
Updated Date:
2003-03-14
Project Name:
JDK
Resolved Date:
2003-03-14
Component:
core-libs
OS:
windows_2000
Sub-Component:
java.util:i18n
CPU:
x86
Priority:
P2
Resolution:
Duplicate
Affected Versions:
1.4.1
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

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
                                     
2003-03-14



Hardware and Software, Engineered to Work Together