JDK-4257314 : RFE: TimeZone only supports year 2000
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version:
    1.2.2,1.2.2_007,1.3.0,1.3.1,1.3.1_19 1.2.2,1.2.2_007,1.3.0,1.3.1,1.3.1_19
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,solaris_2.6,solaris_7,solaris_9,solaris_10 generic,solaris_2.6,solaris_7,solaris_9,solaris_10
  • CPU: generic,x86,sparc
  • Submitted: 1999-07-27
  • Updated: 2000-12-13
  • Resolved: 2000-12-13
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.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
JDK-4388302 - Test of the correct handling of the Solaris host time zone
Duplicate :  
JDK-4358472 - TimeZone:inDaylightTime doen't pass.
Duplicate :  
JDK-6471271 - (tz) New DST rules for North America not yet added to 1.3.1
Duplicate :  
JDK-6515180 - Some 2006 dates showing wrong results regarding DST with 1.3.1_19 JDK
Duplicate :  
JDK-4496763 - Sydney daylight saving must begin in September, not August
Duplicate :  
JDK-4505478 - Incorrect Daylight Savings for JDK 1.2 and JDK 1.3
Relates :  
JDK-6391777 - JDK 1.3 TZ fix required - Related to SUN BASE RFE 6332148
Relates :  
JDK-4328065 - InDayLightTime returns false for Australia/Sydney in September
Description
Kestrel TimeZone implementation does not have any histric TimeZone changes. It only applies rule of year 2000. There are time zone like Australia/Sydney -- has exception on DST on year 2000 only --, or like Iran -- that changes DST rule every year. Without holding histrical data, like UNIX tz do, it's not possible to deal with these time zones.

We have to always update timezone data every year, if the one we have now is correct. This is not good implementation. Also, all the timezone data is hardcoded in TimeZone data. This is lack of maintainancability. TimeZone data will change a lot year by year. Since it's just each country local data.

koushi.takahashi@japan 1999-07-27
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta
14-06-2004
EVALUATION Importing UNIX TZ methodology will require some major rework of current TimeZone implementation. This includes API changes. Won't happen in Kestrel time frame. koushi.takahashi@japan 1999-07-29 This is a known and documented restriction. Changing to an RFE. masayoshi.okutsu@Eng 1999-09-01 Zoneinfo-based time zone support has been implemented. One option is to use the Olson style zoneinfo for the historical DST schedule changes support. masayoshi.okutsu@Eng 2000-01-20 Zoneinfo-based time zone support has been approved. masayoshi.okutsu@Eng 2000-11-22
20-01-2000