-
Bug
-
Resolution: Duplicate
-
P2
-
None
-
1.4.1
-
x86
-
windows_2000
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)
======================================================================
- duplicates
-
JDK-4255109 (tz) TimeZone should support historical time zone name changes
-
- Open
-
- relates to
-
JDK-4844459 setTimeInMillis adding an extra hour as default
-
- Closed
-
-
JDK-6433699 SimpleDateFormat formats 'z' as GMT, 'Z' as +0100
-
- Closed
-