JDK-4329879 : (tz) Doc: TimeZone.getOffset is poorly documented
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.3.0
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2000-04-12
  • Updated: 2017-02-10
Related Reports
Relates :  
Description

Name: skT45625			Date: 04/12/2000


java version "1.2.2"
Classic VM (build 1.2.2-I, green threads, javacomp)


The documentation for TimeZone.getOffset(int, int, int, int, int, int) is
inadequate.  The following questions are all left unanswered by the
documentation:

Do the parameters specify local time, or GMT time?

If you want the offset for April 11, 2000 in EST, why do you have to know the
day of the week?

What is the milliseconds parameter for?  These calls both return the same value
(-7).

  TimeZone zone = TimeZone.getTimeZone("PST");
  zone.getOffset(GregorianCalendar.AD,2000,4,2,1,1);
  zone.TimeZone.getOffset(GregorianCalendar.AD,2000,4,2,1,Integer.MAX_VALUE);

What about 1:00 AM on the day daylight savings starts or ends?  Assuming the
parameters specify local time, then the offset for 4/2/2000 in PST (as called
above) would be -8 for times up to 2:00 AM, and -7 for other times.  But there
seems to be no way to specify the time to that granularity.

Why is era necessary?  Can't it be implied from the year?
(Review ID: 103599) 
======================================================================

Comments
EVALUATION The API doc describes that the `milliseconds' parameter is "the millis in day in standard local time". If the given year value is 0 or negative, the era parameter is adjusted, but era is required to adjust. This should be documented. masayoshi.okutsu@Eng 2000-11-07
07-11-2000