JDK-6936350 : API clarification needed on useDaylightTime() for timezones that have defined usage dates
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_7
  • CPU: generic,sparc
  • Submitted: 2010-03-18
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b132Fixed
Related Reports
Relates :  
JDK-6380023 - (tz) API: some TimeZone methods can't deal with GMT offset and DST rule changes
Relates :  
JDK-7021989 - Missing observesDaylightTime override in ZoneInfo
Description
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.
Comments
PUBLIC COMMENTS API clarification in JDK6 release requires approval of Change Control Committee and may require Maintenance JSR for Java 6 update release.
15-03-2011
EVALUATION - Spec clarification: useDaylightTime() /** * Queries if this time zone uses daylight savings time. - * <p> - * If an underlying <code>TimeZone</code> implementation subclass - * supports historical Daylight Saving Time schedule changes, the - * method refers to the latest Daylight Saving Time schedule - * information. * - * @return true if this time zone uses daylight savings time, - * false, otherwise. + * <p>If an underlying {@code TimeZone} implementation subclass + * supports historical and future Daylight Saving Time schedule + * changes, this method refers to the last known Daylight Saving Time + * rule that can be a future prediction and may not be the same as + * the current rule. Consider calling {@link #observesDaylightTime()} + * if the current rule should also be taken into account. + * + * @return {@code true} if this {@code TimeZone} uses Daylight Saving Time, + * {@code false}, otherwise. + * @see #inDaylightTime(Date) + * @see Calendar#DST_OFFSET */ - Spec clarification: getDSTSavings() /** * Returns the amount of time to be added to local standard time * to get local wall clock time. - * <p> - * The default implementation always returns 3600000 milliseconds - * (i.e., one hour) if this time zone observes Daylight Saving - * Time. Otherwise, 0 (zero) is returned. - * <p> - * If an underlying TimeZone implementation subclass supports - * historical Daylight Saving Time changes, this method returns - * the known latest daylight saving value. + * + * <p>The default implementation returns 3600000 milliseconds + * (i.e., one hour) if a call to {@link #useDaylightTime()} + * returns {@code true}. Otherwise, 0 (zero) is returned. + * + * <p>If an underlying {@code TimeZone} implementation subclass + * supports historical and future Daylight Saving Time schedule + * changes, this method returns the amount of saving time of the + * last known Daylight Saving Time rule that can be a future + * prediction. + * + * <p>If the amount of saving time at any given time stamp is + * required, construct a {@link Calendar} with this {@code + * TimeZone} and the time stamp, and call {@link Calendar#get(int) + * Calendar.get}{@code (}{@link Calendar#DST_OFFSET}{@code )}. * * @return the amount of saving time in milliseconds * @since 1.4 + * @see #inDaylightTime(Date) + * @see #getOffset(long) + * @see #getOffset(int,int,int,int,int,int) + * @see Calendar#ZONE_OFFSET */ - Added the following method to TimeZone. /** * Returns {@code true} if this {@code TimeZone} is currently in * Daylight Saving Time, or if a transition from Standard Time to * Daylight Saving Time occurs at any future time. * * <p>The default implementation returns {@code true} if * {@code useDaylightTime()} or {@code inDaylightTime(new Date())} * returns {@code true}. * * @return {@code true} if this {@code TimeZone} is currently in * Daylight Saving Time, or if a transition from Standard Time to * Daylight Saving Time occurs at any future time; {@code false} * otherwise. * @since 1.7 * @see #useDaylightTime() * @see #inDaylightTime(Date) * @see Calendar#DST_OFFSET */ public boolean observesDaylightTime() - Added the following method to SimpleTimeZone. /** * Returns {@code true} if this {@code SimpleTimeZone} observes * Daylight Saving Time. This method is equivalent to {@link * #useDaylightTime()}. * * @return {@code true} if this {@code SimpleTimeZone} observes * Daylight Saving Time; {@code false} otherwise. * @since 1.7 */ public boolean observesDaylightTime()
16-02-2011
EVALUATION Needs to clarify what the latest rule means.
25-01-2011