-
Type:
Bug
-
Status: Open
-
Priority:
P4
-
Resolution: Unresolved
-
Affects Version/s: 1.4.0, 6
-
Fix Version/s: None
-
Component/s: core-libs
-
Labels:None
-
Subcomponent:
-
Understanding:Fix Understood
-
Introduced In Version:
-
CPU:generic, x86
-
OS: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
-