-
Bug
-
Resolution: Fixed
-
P3
-
6, 7
-
b132
-
generic, sparc
-
generic, solaris_7
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2206796 | 6u25 | Sean Coffey | P2 | Closed | Won't Fix |
The licensee would like to see an API modification done to better explain the usage for useDaylightTime() for TimeZones whom have a defined start and end date.
Issue:
If you have a TimeZone that has a last rule that says Start DST 2010, and end in 2020. The method useDatelightTime() would return false. This is correct since the method does not have a Date object associated with it, but rather checks the last rule to see if it "follows" DST. In the example since there is an end date, the method would return false if checked in 2010. This is confusing since the TimeZone is currently observing DST and will be for 10 more years...
Suggest to either clarify the API definition for useDaylightTime or to modify the method to better account for such examples as the Fiji 2009/2010 and 2010/2011 change. Austraila also had this issue when they observed a one time DST change for the Olympics.
TimeZone.getDSTSavings() can also give similiar mis-leading results.
Issue:
If you have a TimeZone that has a last rule that says Start DST 2010, and end in 2020. The method useDatelightTime() would return false. This is correct since the method does not have a Date object associated with it, but rather checks the last rule to see if it "follows" DST. In the example since there is an end date, the method would return false if checked in 2010. This is confusing since the TimeZone is currently observing DST and will be for 10 more years...
Suggest to either clarify the API definition for useDaylightTime or to modify the method to better account for such examples as the Fiji 2009/2010 and 2010/2011 change. Austraila also had this issue when they observed a one time DST change for the Olympics.
TimeZone.getDSTSavings() can also give similiar mis-leading results.
- backported by
-
JDK-2206796 API clarification needed on useDaylightTime() for timezones that have defined usage dates
- Closed
- relates to
-
JDK-7021989 Missing observesDaylightTime override in ZoneInfo
- Closed
-
JDK-6380023 (tz) API: some TimeZone methods can't deal with GMT offset and DST rule changes
- Open