No, on to není "logicky stejný postup". Cituji javadoc k java.util.Calendar
(http://java.sun.com/j2se/1.4.2/docs/api/):
************************* citat ********************
set(f, value) changes field f to value. In addition, it sets an internal member
variable to indicate that field f has been changed. Although field f is changed
immediately, the calendar's milliseconds is not recomputed until the next call
to get(), getTime(), or getTimeInMillis() is made. Thus, multiple calls to
set() do not trigger multiple, unnecessary computations. As a result of
changing a field using set(), other fields may also change, depending on the
field, the field value, and the calendar system. In addition, get(f) will not
necessarily return value after the fields have been recomputed. The specifics
are determined by the concrete calendar class.
Example: Consider a GregorianCalendar originally set to August 31, 1999.
Calling set(Calendar.MONTH, Calendar.SEPTEMBER) sets the calendar to September
31, 1999. This is a temporary internal representation that resolves to October
1, 1999 if getTime()is then called. However, a call to
set(Calendar.DAY_OF_MONTH, 30) before the call to getTime() sets the calendar
to September 30, 1999, since no recomputation occurs after set() itself.
add(f, delta) adds delta to field f. This is equivalent to calling set(f,
get(f) + delta) with two adjustments:
Add rule 1. The value of field f after the call minus the value of field f
before the call is delta, modulo any overflow that has occurred in field f.
Overflow occurs when a field value exceeds its range and, as a result, the next
larger field is incremented or decremented and the field value is adjusted back
into its range.
Add rule 2. If a smaller field is expected to be invariant, but it is
impossible for it to be equal to its prior value because of changes in its
minimum or maximum after field f is changed, then its value is adjusted to be
as close as possible to its expected value. A smaller field represents a
smaller unit of time. HOUR is a smaller field than DAY_OF_MONTH. No adjustment
is made to smaller fields that are not expected to be invariant. The calendar
system determines what fields are expected to be invariant.
In addition, unlike set(), add() forces an immediate recomputation of the
calendar's milliseconds and all fields.
Example: Consider a GregorianCalendar originally set to August 31, 1999.
Calling add(Calendar.MONTH, 13) sets the calendar to September 30, 2000. Add
rule 1 sets the MONTH field to September, since adding 13 months to August
gives September of the next year. Since DAY_OF_MONTH cannot be 31 in September
in a GregorianCalendar, add rule 2 sets the DAY_OF_MONTH to 30, the closest
possible value. Although it is a smaller field, DAY_OF_WEEK is not adjusted by
rule 2, since it is expected to change when the month changes in a
GregorianCalendar.
****************** konec citatu ************************
Což, pokud dovedu posoudit, přesně popisuje rozdíl v příkladu. Sám jsem s tím
nějakou dobu zápasil, než se mi to ujasnilo :-))
Špekem v java.util.Calendar jsou spíše numerické hodnoty konstant ...
Mirek
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ondřej Fafejta
Sent: Monday, June 18, 2007 3:57 PM
To: Java
Subject: java.util.Calendar
Zdravím konferenci!
Musím se podělit o špek s java.util.Calendar.
Mějme příklad:
Calendar validFrom = Calendar.getInstance();
validFrom.set(2007,Calendar.JANUARY,30);
Calendar validTo = (Calendar) validFrom.clone();
Potřeboval bych přidat 1 měsíc k validTo.
Která z možností je správně?
a) validTo.set(Calendar.MONTH, validTo.get(Calendar.MONTH) + 1);
b) validTo.add(Calendar.MONTH,1);
Nebudu vás napínat.
Výsledky jsou následující:
a) 2.3.2007
b) 28.2.2007 - ANO B je správně!
Kdo by to čekal,
že logicky stejným postupem získám dvě různá řešení :-).
Fafi
