JDK-4230123 : TimeZones loaded unnecessarily
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.2.0,1.2.1,1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt,windows_xp
  • CPU: generic,x86
  • Submitted: 1999-04-15
  • Updated: 2013-11-01
  • 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-4177488 - GregorianCalendar - poor performance of new
Duplicate :  
JDK-6609371 - (tz) New DST rules is not in effect in 1.3.1_18
Relates :  
JDK-4845752 - (tz) Wrong behavior JDK 1.3.1 in GregorianCalendar at DST boundary time
Relates :  
JDK-4495052 - RFE: Java should support complete set of Olson time zones
Relates :  
JDK-6391777 - JDK 1.3 TZ fix required - Related to SUN BASE RFE 6332148
Relates :  
JDK-4505478 - Incorrect Daylight Savings for JDK 1.2 and JDK 1.3
Relates :  
JDK-4716648 - TimeZone.getOffset() does not return a modified offset in 0095
Relates :  
JDK-4763654 - (tz) RFE: consider timezone related files to be put in single jar
Relates :  
JDK-4645263 - TimeZone factory methods return instance not deserializable in previous releases
Relates :  
JDK-4771597 - Y2k test TZ_useDaylightTime_y2k fails
Relates :  
JDK-6471271 - (tz) New DST rules for North America not yet added to 1.3.1
Relates :  
JDK-4402792 - api/java_util/serialization/descriptions.html, Merlin, Sparc, x86, B46, JCK13
Relates :  
JDK-4401148 - ClassCastException when casting from TimeZone to SimpleTimeZone
Relates :  
JDK-4402984 - A daylight time problem in merlin b46 and ladybird b13
Description
TimeZone.java seems to eagerly load a whole bunch of SimpleTimeZones in
the inner class TimeZoneData.  We should see if this can be delayed somehow
so that the developer only pays for what they are using!
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta
14-06-2004
SUGGESTED FIX New Time Zone Support Mechanism Proposal Revision: 2 | (differences from the previous revision are indicated by change bars) | Release: Merlin Problem: The current time zone support in J2SE has weaknesses in the following areas. * DST Schedule Changes [bugID: 4257314] It's common that a time zone changes its Daylight Saving Time (DST) schedules or its GMT offsets, or stops or resumes observing DST. For example, in some Australia time zones, such as in Sydney, daylight saving time starts earlier than the regular year only in this year for the Olympic games. The SimpleTimeZone class can represent only a single set of DST start/end rules and, therefore, can't deal with DST schedule changes in a time zone. If a 2001 date is given to SimpeTimeZone.getOffset() in the Sydney time zone on Kestrel, the result may or may not be correct, depending on the given date, because DST schedules in 2000 are taken for all time zones. * Performance [bugID: 4230123] When initializing time zone data in a Java runtime, it creates about 320 SimpleTimeZone objects and a hash table with those objects so that a time zone can be searched with a time zone ID (e.g., TimeZone.getTimeZone(String ID)). However, usually an application that deals with date/time requires only one local time zone. Creating ~320 SimpleTimeZone objects is a waste of CPU cycles (~200ms on 200MHz Ultra-2) and memory space (~50KB). Also, the current SimpleTimeZone defines a rule for daylight saving time schedule, such as "the first Sunday of April", and the rule has to be interpreted with a concrete date at run-time. This run-time calculation also affects run-time performance. * Maintainability [bugID: 4360149] Currently, all time zone data is hard coded in java/util/TimeZone.java. While time zone change information is publicly available (known as the Olson public source), it's very difficult for Java 2 releases to deal with such changes in a timely manner. If we provide a separate jar file for time zone data, we don't need to provide a patch release for time zone changes. (We often have escalation on fixing old time zone data by multi-national companies, such as HP.) Also, this allows other Java platforms (e.g., J2ME) to provide a subset or superset of the J2SE supported time zones. A good framework for time zone support is publicly available, known as the Olson public source (zoneinfo). Major operating systems, including Solaris and Linux, use its zoneinfo-based solution. Some prototyping efforts have been made. Based on the prototyping analysis, we are able to eliminate the SimpleTimeZone objects overhead and get faster runtime calendar calculation (4-30%) and reduced heap size (30-500KB less) in the Calendar and TimeZone | area. The proposal is to incorporate the same approach as the Olson public domain time zone support into Java 2. Requesters: Masayoshi Okutsu RFE/BUG: 4257314 - RFE: TimeZone only supports year 2000 4230123 - TimeZones loaded unnecessarily 4379852 - RFE: tzdata2000g to be incorporated | Proposed Solution and API Change: The following zoneinfo-based solution is proposed. * Introduce an abstract class sun.util.calendar.ZoneInfo (a java.util.TimeZone subclass) that holds a database of DST transition information, including historical and future changes. This will eliminate some expensive calendar fields interpretations (year, month, day, etc.) to determine whether DST is in effect or not with a given date. Because Java represents time in a long word, it is required to be able to support large year numbers. The ZoneInfo class has a transition table until year 2037 (the same as UNIX systems) and | delegate all operations to a SimpeTimeZone object if a date beyond 2037 is given. ZoneInfo will be a Sun private class for Merlin because | it's planned to provide a new set of classes to deal with calendar and time zone information in Tiger. We should minimize API changes in Merlin. * Introduce a set of zoneinfo data files in the <JDK_HOME>/lib/zi | directory. | o A zoneinfo file path name (relative from <JDK_HOME>/lib/zi) | represents a time zone ID. For example, the time zone ID | "America/Los_Angeles" is mapped to the file path | "<JDK_HOME>/lib/zi/America/Los_Angeles" on UNIX or | "<JDK_HOME>\lib\zi\America\Los_Angeles" on Win32. | o When instantiating ZoneInfo, the object is initialized with time | zone data that is read from a corresponding date file. | o The "ZoneInfoMappings" file under the directory contains an alias | table for supporting the JDK 1.1.x short time zone IDs (e.g., "PST" | for "America/Los_Angeles") and a name table for enumerating all time| zone IDs for the getAvailableIDs() methods support. | * Change the TimeZone.getDefault and TimeZone.getTimeZone methods to return a ZoneInfo instance. (The Calendar.setTimeZone, DateFormat.setTimeZone, and TimeZone.setDefault methods will still work with SimpleTimeZone.) * Automate production of zoneinfo data files from the Olson public source | text files during the build process so that J2SE can quickly catch up | with the latest distribution of the public time zone information. An | internal tool, called "javazic", which is equivalent to Solaris zic(1M) | will be provided to generate zoneinfo data files. This tool will be for | sun private use only in Merlin. | * Because the ZoneInfo class is able to support historical DST schedule and GMT offset changes, any TimeZone and Calendar API descriptions that assume a single DST schedule and/or a single GMT offset at the abstraction level will be modified to clarify the dependency. The following changes will be made. o Add the following sentence to TimeZone.getOffset(int, int, int, int, int, int) This method returns a historically correct offset if an underlying TimeZone implementation subclass supports historical Daylight Saving Time schedule and GMT offset changes. o Add the following sentences to TimeZone.getRawOffset() If an underlying TimeZone implementation subclass supports historical GMT offset changes, the method returns the raw offset value of the current date. In Honolulu, for example, its raw offset changed from GMT-10:30 to GMT-10:00 in 1947, and this method returns -36000000 milliseconds (i.e., -10 hours). o Add the following sentences to TimeZone.setRawOffset(int) If an underlying TimeZone implementation subclass supports historical GMT offset changes, the specified GMT offset is set as the latest GMT offset and the difference from the known latest GMT offset value is used to adjust all historical GMT offset values. o Add the following sentence to TimeZone.useDaylightTime() If an underlying TimeZone implementation subclass supports historical Daylight Saving Time schedule changes, the method refers to the latest Daylight Saving Time schedule information. o Add the following sentence to Calendar.ZONE_OFFSET This field reflects the correct GMT offset value of the time zone of this Calendar if the TimeZone implementation subclass supports historical GMT offset changes. o Add the following sentence to Calendar.DST_OFFSET This field reflects the correct daylight saving offset value of the time zone of this Calendar if the TimeZone implementation subclass supports historical Daylight Saving Time schedule changes. Reviewed by: Norbert Lindenberg Implementation: The prototyping has been completed by Masayoshi Okutsu. The implementation of the production version for Merlin is being done by Masayoshi Okutsu and Yuka Kamiya. The implementation (sun private classes spec and code) will be reviewed by the I18N team members. Risk assessment: The following are known technical risks. * The TimeZone API documentation does not specify that the TimeZone factory methods return a SimpleTimeZone instance. However, if there is any application that assumes it's a SimpleTimeZone and calls SimpleTimeZone specific methods, this change will break the application. * The total size of zoneinfo data files is about 80KB after | compression. This will affect download time of JRE/SDK. | * If an application sets a SimpleTimeZone object to a Calendar explicitly (i.e., calling the setTimeZone method), some run-time calculations will be slower than the previous release. SQE (product testing) impact: The assumption of having a single DST start/end rule in a time zone is no longer valid. If any time zone QA programs have this assumption, such programs have to be modified to remove the assumption. On the other hand, because the new ZoneInfo can deal with correct DST transition data in the past, time zone test programs or golden data won't need to be modified to deal with the latest DST schedule changes unless there are any errors in the past data with the Olson public time zone information. A separate set of SimpleTimeZone testing should be provided because the TimeZone factory methods no longer return a SimpleTimeZone object. Approved by Bae-Chul Kim. JCK (compatibility testing) impact: JCK doesn't (shouldn't) depend on contents of time zone data. Therefore, this new ZoneInfo-based implementation shouldn't affect any existing JCK tests. Approved by Kirill Soshalsky. Doc impact: The documentation for the semantic changes in the existing methods and fields above is considered sufficient. Approved by Alan Sommerer. Localization impact: None. Internationalization impact: This change improves the J2SE internationalization functionality. Security impact: None. Legal impact: No known impact. APPENDIX. Performance Test Results The following are the results of small benchmark tests using 1.4 with the zone info modifications as of October 24, 2000. CPU time was measured using | the time command of tcsh on Solaris. Heap sizes were measured using | hprof. "1.4.0" has the current SimpleTimeZone-based time zone support. "1.4.0 | zoneinfo" has the new ZoneInfo support. | * TimeZone.getDefault() * This test program calls only TimeZone.getDefault() once. RESULTS (Ultra-60/450MHz, HotSpot mixed mode) | 1.4.0 1.4.0 Performance zoneinfo Difference 0.53 sec 0.51 sec +4 % | 1012.2 KB 839.2 KB -173.0 KB | * GMT time and date fields conversion * This test program performs round-trip conversions between GMT milliseconds and date fields 350,641 times (every hour from 1970 to 2020), which heavily involves getOffset() calls. RESULTS (Ultra-60/450MHz, HotSpot mixed mode): | Time Zone 1.4.0 1.4.0 Performance zoneinfo Difference US Pacific Time 10.9 sec 9.4 sec +14 % | 1261.3 KB 529.0 KB -732.3 KB | Japan Standard Time 10.0 sec 7.1 sec +29 % | (no daylight saving) 1001.7 KB 494.9 KB -506.8 KB | masayoshi.okutsu@Eng 2000-11-09
09-11-2000
EVALUATION Currently TimeZone creates ~320 SimpleTimeZone objects so that the current timezone where JVM is running can be searched. This affects run-time performance. masayoshi.okutsu@Eng 1999-05-18 Prototyping based on the Olson zoneinfo mechanism completely eliminated the TimeZoneData overhead. It saved 200 ms out of 660 ms of "new GregorianCalendar()" under Kestrel on 200MHz Ultra-2. Also saved 50KB of heap usage. masayoshi.okutsu@Eng 2000-01-20 Zoneinfo-based time zone support has been approved. masayoshi.okutsu@Eng 2000-11-09
20-01-2000