JDK-6433179 : (tz) Incorrect DST end for America/Winnipeg and Canada/Central in 2038+
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-06-02
  • Updated: 2014-05-06
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u4Fixed 7 b08Fixed
Related Reports
Relates :  
Description
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 ----------

Comments
EVALUATION It wasn't related to 4845752. But it was a regression in the SimpleTimeZone reimplementation in 5.0. The time-mode for the end rule wasn't checked correctly.
28-12-2006

EVALUATION GregorianCalendar can't handle DST transitions correctly with a SimpleTimeZone. See also 4845752.
05-06-2006