-
Bug
-
Resolution: Fixed
-
P4
-
5.0
-
b08
-
x86
-
windows_xp
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2145099 | 6u4 | Yuka Kamiya | P3 | Resolved | Fixed | b01 |
FULL PRODUCT VERSION :
JRE 1.5.0_06
ADDITIONAL OS VERSION INFORMATION :
Windows XP SP2
A DESCRIPTION OF THE PROBLEM :
For years after 2038, getOffset(long) on java.util.Timezone reports that the timezones America/Winnipeg and Canada/Central reports that DST ends one hour earlier than it actually should.
Curiously, the last rule listed in TimeZone.toString() reports the correct information for the time zones, including the correct end time rule (SimpleTimeZone.STANDARD_TIME). However, the actual instance of SimpleTimeZone used has the end time rule of WALL_TIME, accounting for the one hour discrepency.
All other timezones appear to behave correctly in this regard.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Construct a calendar or time in the last hour of DST in 2038 or a later year. Call TimeZone.getTimeZone("America/Winnipeg").getOffset(long) using that time. It will report that the offset is -6 hours, which is the standard offset, not the daylight offset.
Specifically, longs in the range 2172121200000-2172124799999 result in a return of -21600000, not -18000000.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
As described.
ACTUAL -
As described.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.Calendar;
import java.util.TimeZone;
public class Test
{
public static void main(String[] args)
{
TimeZone zz = TimeZone.getTimeZone("America/Winnipeg");
// set to two hours after midnight on 10/31/2038 (last day of DST)
// = one hour before the end of dst, which ends at 3am local wall time
Calendar cal = Calendar.getInstance(zz);
cal.set(2038, Calendar.OCTOBER, 31, 0, 0, 0);
cal.add(Calendar.HOUR_OF_DAY, 2);
if (zz.getOffset(cal.getTimeInMillis()) == zz.getRawOffset())
{
System.out.println("Daylight time is over early!");
}
else
{
System.out.println("Daylight time still going.");
}
}
}
---------- END SOURCE ----------
JRE 1.5.0_06
ADDITIONAL OS VERSION INFORMATION :
Windows XP SP2
A DESCRIPTION OF THE PROBLEM :
For years after 2038, getOffset(long) on java.util.Timezone reports that the timezones America/Winnipeg and Canada/Central reports that DST ends one hour earlier than it actually should.
Curiously, the last rule listed in TimeZone.toString() reports the correct information for the time zones, including the correct end time rule (SimpleTimeZone.STANDARD_TIME). However, the actual instance of SimpleTimeZone used has the end time rule of WALL_TIME, accounting for the one hour discrepency.
All other timezones appear to behave correctly in this regard.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Construct a calendar or time in the last hour of DST in 2038 or a later year. Call TimeZone.getTimeZone("America/Winnipeg").getOffset(long) using that time. It will report that the offset is -6 hours, which is the standard offset, not the daylight offset.
Specifically, longs in the range 2172121200000-2172124799999 result in a return of -21600000, not -18000000.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
As described.
ACTUAL -
As described.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.Calendar;
import java.util.TimeZone;
public class Test
{
public static void main(String[] args)
{
TimeZone zz = TimeZone.getTimeZone("America/Winnipeg");
// set to two hours after midnight on 10/31/2038 (last day of DST)
// = one hour before the end of dst, which ends at 3am local wall time
Calendar cal = Calendar.getInstance(zz);
cal.set(2038, Calendar.OCTOBER, 31, 0, 0, 0);
cal.add(Calendar.HOUR_OF_DAY, 2);
if (zz.getOffset(cal.getTimeInMillis()) == zz.getRawOffset())
{
System.out.println("Daylight time is over early!");
}
else
{
System.out.println("Daylight time still going.");
}
}
}
---------- END SOURCE ----------
- backported by
-
JDK-2145099 (tz) Incorrect DST end for America/Winnipeg and Canada/Central in 2038+
-
- Resolved
-
- relates to
-
JDK-4845752 (tz) Wrong behavior JDK 1.3.1 in GregorianCalendar at DST boundary time
-
- Resolved
-