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.
