-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
1.3.0, 1.4.2
-
None
-
generic
-
generic
As a result of the fix for bug #4254589, the date based add()/roll() behaviour has been documented out. However, for those based on time (milliseconds) calcuration is still not clear. e.g. roll(DAY_OF_YEAR, 30) will advance 30(days) * 24 * 60 * 60 * 1000 milliseconds, not 30 days -- this affects the result day, if there is DST switching between. Say, "4/1/99 0:0 PST" roll(DAY_OF_YEAR, 30) will result in "5/1/99 1:00 PST".
1) add() almost all fields (except ERA, YEAR, MONTH) are computed based on milliseconds.
2) roll() DAY_OF_YEAR,DAY_OF_WEEK,DAY_OF_WEEK_IN_MONTH are all computed on milliseconds base.
3) Also, add()/roll() ZONE_OFFSET, DST_OFFSET will throw IllegalArgumentException.
All these spec should be documented out.
koushi.takahashi@japan 1999-10-15
1) add() almost all fields (except ERA, YEAR, MONTH) are computed based on milliseconds.
2) roll() DAY_OF_YEAR,DAY_OF_WEEK,DAY_OF_WEEK_IN_MONTH are all computed on milliseconds base.
3) Also, add()/roll() ZONE_OFFSET, DST_OFFSET will throw IllegalArgumentException.
All these spec should be documented out.
koushi.takahashi@japan 1999-10-15
- duplicates
-
JDK-4846769 Calendar: can't set value for ZONE_OFFSET&DST_OFFSET and roll() throw exception
-
- Closed
-
- relates to
-
JDK-4254589 Doc: GregorianCalendar needs to specify behavior for leap year add/roll
-
- Resolved
-