JDK-4716648 : TimeZone.getOffset() does not return a modified offset in 0095
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-07-18
  • Updated: 2002-07-18
  • Resolved: 2002-07-18
Related Reports
Relates :  
Description

Name: rmT116609			Date: 07/18/2002


FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
sun.util.calendar.ZoneInfo, which is used as the TimeZone class in java.util.GregorianCalendar, does not return a modified offset in case of daylight savings when getOffset() is called for the following case:

GregorianCalendar c = new GregorianCalendar(95,5,1);
int offset = c.getTimeZone().getOffset(c.get(Calendar.ERA),
                          c.get(Calendar.YEAR),
                          c.get(Calendar.MONTH),
                          c.get(Calendar.DAY_OF_MONTH),
                          c.get(Calendar.DAY_OF_WEEK),
                          c.get(Calendar.MILLISECOND));

In jdk 1.4, 1.4.1-beta the offset is -28800000, in jdk 1.3.1 it is -25200000. In both cases the id of the TimeZone is America/Los_Angeles.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. run code snippet from description under jdk 1.4, 1.4.1-beta and 1.3.1

EXPECTED VERSUS ACTUAL BEHAVIOR :
offset should be -25200000 but is -28800000

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Calendar;
import java.util.GregorianCalendar;

public class Test {

  public static void main(String[] args) {
    
    GregorianCalendar c = new GregorianCalendar(96,5,1);
    int offset = c.getTimeZone().getOffset(c.get(Calendar.ERA),
                                           c.get(Calendar.YEAR),
                                           c.get(Calendar.MONTH),
                                           c.get(Calendar.DAY_OF_MONTH),
                                           c.get(Calendar.DAY_OF_WEEK),
                                           c.get(Calendar.MILLISECOND));

    System.out.println("offset " + offset);

  }
  
}

---------- END SOURCE ----------

Release Regression From : 1.3.1_04
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: 159536) 
======================================================================

Comments
EVALUATION I assume that the user meant year 95 or 96, not 1995 or 1996. Since 1.4.0, TimeZone returns ZoneInfo which supports historically correct zone offsets. According to the Olson time zone data, local standard time was introduced in 1883 and DST started in 1918. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 max - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D Rule US 1975 only - Feb 23 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 max - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:00 -8:00 US P%sT 1946 -8:00 CA P%sT 1967 -8:00 US P%sT Strictly speaking, before 1883, it should return the local mean time offset. But currently it returns the local standard time. If the user needs to assume that the current DST transition rules were valid in 95 and 96, create a SimpleTimeZone object. ###@###.### 2002-07-18
18-07-2002