ICU4J TimeZone#setDefault messes up historic time zone rules in JDK Calendar

Description

While investigating #6278, I found this design problem.

com.ibm.icu.util.TimeZone#setDefault wraps an instance of ICU TimeZone using JDK adapter class - com.ibm.icu.impl.TimeZoneAdapter, which extends java.util.TimeZone, and set the instance as the default Java TimeZone. However, java.util.TimeZone does not have public APIs which return base offset and DST saving at the given time.

Sun JDK has a private class - sun.util.calendar.ZoneInfo, which support such functionality. java.util.Calendar/java.util.Date calls a JDK private class, which checks if the default TimeZone is a ZoneInfo. If not, use the public TimeZone methods - getRawOffset() and inDaylightTime()/getDSTSavings(). These APIs are inherited from JDK 1.1 and do not support historic rule changes. Thus, if com.ibm.icu.util.TimeZone#setDefault is called, JDK Calendar/Date are no longer able to support historic time zone offsets properly.

To avoid this problem, ICU should probably not call java.util.TimeZone#setDefault with an instance of TimeZone subclass wrapping ICU4J OlsonTimeZone. Instead, just create a matching JDK TimeZone with the Olson zone ID and set it as the JDK's default.

Activity

Show:
TracBot
June 30, 2018, 11:48 PM
Trac Comment 3 by —2016-10-05T23:16:32.118Z

Milestone 4.1.1 deleted

Fixed

Assignee

Yoshito Umaoka

Reporter

Yoshito Umaoka

Components

Labels

None

Reviewer

None

Priority

major

Time Needed

Hours

Fix versions