-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
1.4.0, 6
-
None
-
Fix Understood
-
generic, x86
-
generic, windows_xp
TimeZone has methods that assume the GMT offset of a time zone would never change. However, it does change in the real world. That assumption causes problems especially with future changes. Those methods are:
getRawOffset()
getAvailableIds(int)
We need overloads that take a time stamp as:
getRawOffset(long)
getAvailableIds(int, long)
Note that Calendar.get(Calendar.ZONE_OFFSET) returns the correct GMT offset at the time represented by the Calendar instance.
getDSTSavings() has the same problem.
useDaylightTime() has the same problem.
getRawOffset()
getAvailableIds(int)
We need overloads that take a time stamp as:
getRawOffset(long)
getAvailableIds(int, long)
Note that Calendar.get(Calendar.ZONE_OFFSET) returns the correct GMT offset at the time represented by the Calendar instance.
getDSTSavings() has the same problem.
useDaylightTime() has the same problem.
- duplicates
-
JDK-6645262 (tz) Australia/Perth TimeZone useDaylightTime() returns incorrect boolean (False)
-
- Closed
-
-
JDK-8061439 Java should handle user defined TimeZone subclass instances supporting historic
-
- Closed
-
- relates to
-
JDK-5055567 (tz) TimeZone.getAvailableIDs(int) may produce inconsistent info with getRawOffset()
-
- Resolved
-
-
JDK-6907174 Confusing ZoneInfo details displayed for Pacific/Fiji TZ
-
- Closed
-
-
JDK-6936350 API clarification needed on useDaylightTime() for timezones that have defined usage dates
-
- Closed
-