java.lang.Objectjava.util.Calendar
All Implemented Interfaces:
Cloneable, Comparable, Serializable
Direct Known Subclasses:
JapaneseImperialCalendar, GregorianCalendar
Subclasses of {@code Calendar} interpret a {@code Date} according to the rules of a specific calendar system.
Like other locale-sensitive classes, {@code Calendar} provides a class method, {@code getInstance}, for getting a default instance of this class for general use. {@code Calendar}'s {@code getInstance} method returns a calendar whose locale is based on system settings and whose time fields have been initialized with the current date and time:
Calendar rightNow = Calendar.getInstance()
A {@code Calendar} object can produce all the time field values needed to implement the date-time formatting for a particular language and calendar style (for example, Japanese-Gregorian, Japanese-Traditional). {@code Calendar} defines the range of values returned by certain fields, as well as their meaning. For example, the first month of the year has value {@code MONTH} == {@code JANUARY} for all calendars. Other values are defined by the concrete subclass, such as {@code ERA} and {@code YEAR}. See individual field documentation and subclass documentation for details.
When a {@code Calendar} is lenient, it accepts a wider range of field values than it produces. For example, a lenient {@code GregorianCalendar} interprets {@code MONTH} == {@code JANUARY}, {@code DAY_OF_MONTH} == 32 as February 1. A non-lenient {@code GregorianCalendar} throws an exception when given out-of-range field settings. When calendars recompute field values for return by {@code get()}, they normalize them. For example, a {@code GregorianCalendar} always produces {@code DAY_OF_MONTH} values between 1 and the length of the month.
{@code Calendar} defines a locale-specific seven day week using two parameters: the first day of the week and the minimal days in first week (from 1 to 7). These numbers are taken from the locale resource data when a {@code Calendar} is constructed. They may also be specified explicitly through the API.
When setting or getting the {@code WEEK_OF_MONTH} or {@code WEEK_OF_YEAR} fields, {@code Calendar} must determine the first week of the month or year as a reference point. The first week of a month or year is defined as the earliest seven day period beginning on {@code getFirstDayOfWeek()} and containing at least {@code getMinimalDaysInFirstWeek()} days of that month or year. Weeks numbered ..., -1, 0 precede the first week; weeks numbered 2, 3,... follow it. Note that the normalized numbering returned by {@code get()} may be different. For example, a specific {@code Calendar} subclass may designate the week before week 1 of a year as week n of the previous year.
When computing a {@code Date} from time fields, two special circumstances may arise: there may be insufficient information to compute the {@code Date} (such as only year and month but no day in the month), or there may be inconsistent information (such as "Tuesday, July 15, 1996" -- July 15, 1996 is actually a Monday).
Insufficient information. The calendar will use default information to specify the missing fields. This may vary by calendar; for the Gregorian calendar, the default for a field is the same as that of the start of the epoch: i.e., YEAR = 1970, MONTH = JANUARY, DATE = 1, etc.
Inconsistent information. If fields conflict, the calendar will give preference to fields set more recently. For example, when determining the day, the calendar will look for one of the following combinations of fields. The most recent combination, as determined by the most recently set single field, will be used.
For the time of day:MONTH + DAY_OF_MONTH MONTH + WEEK_OF_MONTH + DAY_OF_WEEK MONTH + DAY_OF_WEEK_IN_MONTH + DAY_OF_WEEK DAY_OF_YEAR DAY_OF_WEEK + WEEK_OF_YEAR
HOUR_OF_DAY AM_PM + HOUR
Note: There are certain possible ambiguities in interpretation of certain singular times, which are resolved in the following ways:
The date or time format strings are not part of the definition of a calendar, as those must be modifiable or overridable by the user at runtime. Use java.text.DateFormat to format dates.
Field manipulation methods
{@code Calendar} fields can be changed using three methods: {@code set()}, {@code add()}, and {@code roll()}.
{@code set(f, value)} changes field {@code f} to {@code value}. In addition, it sets an internal member variable to indicate that field {@code f} has been changed. Although field {@code f} is changed immediately, the calendar's milliseconds is not recomputed until the next call to {@code get()}, {@code getTime()}, or {@code getTimeInMillis()} is made. Thus, multiple calls to {@code set()} do not trigger multiple, unnecessary computations. As a result of changing a field using {@code set()}, other fields may also change, depending on the field, the field value, and the calendar system. In addition, {@code get(f)} will not necessarily return {@code value} after the fields have been recomputed. The specifics are determined by the concrete calendar class.
Example: Consider a {@code 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 {@code getTime()}is
then called. However, a call to {@code set(Calendar.DAY_OF_MONTH, 30)}
before the call to {@code getTime()} sets the calendar to September
30, 1999, since no recomputation occurs after {@code set()} itself.
{@code add(f, delta)} adds {@code delta} to
field {@code f}. This is equivalent to calling set(f,
get(f) + delta)
with two adjustments:
Add rule 1. The value of field {@code f} after the call minus the value of field {@code f} before the call is {@code delta}, modulo any overflow that has occurred in field {@code 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 {@code 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. {@code HOUR} is a smaller field than {@code 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 {@code set()}, {@code add()} forces an immediate recomputation of the calendar's milliseconds and all fields.
Example: Consider a {@code GregorianCalendar} originally set to August 31, 1999. Calling {@code add(Calendar.MONTH, 13)} sets the calendar to September 30, 2000. Add rule 1 sets the {@code MONTH} field to September, since adding 13 months to August gives September of the next year. Since {@code DAY_OF_MONTH} cannot be 31 in September in a {@code GregorianCalendar}, add rule 2 sets the {@code DAY_OF_MONTH} to 30, the closest possible value. Although it is a smaller field, {@code DAY_OF_WEEK} is not adjusted by rule 2, since it is expected to change when the month changes in a {@code GregorianCalendar}.
{@code roll(f, delta)} adds {@code delta} to field {@code f} without changing larger fields. This is equivalent to calling {@code add(f, delta)} with the following adjustment:
Roll rule. Larger fields are unchanged after the call. A larger field represents a larger unit of time. {@code DAY_OF_MONTH} is a larger field than {@code HOUR}.
Example: Consider a {@code GregorianCalendar} originally
set to August 31, 1999. Calling roll(Calendar.MONTH,
8) sets
the calendar to April 30, 1999. Add rule 1 sets the
{@code MONTH} field to April. Using a {@code GregorianCalendar},
the {@code DAY_OF_MONTH} cannot be 31 in the month April. Add rule 2
sets it to the closest possible value, 30. Finally, the roll rule
maintains the {@code YEAR} field value of 1999.
Example: Consider a {@code GregorianCalendar} originally set to Sunday June 6, 1999. Calling {@code roll(Calendar.WEEK_OF_MONTH, -1)} sets the calendar to Tuesday June 1, 1999, whereas calling {@code add(Calendar.WEEK_OF_MONTH, -1)} sets the calendar to Sunday May 30, 1999. This is because the roll rule imposes an additional constraint: The {@code MONTH} must not change when the {@code WEEK_OF_MONTH} is rolled. Taken together with add rule 1, the resultant date must be between Tuesday June 1 and Saturday June 5. According to add rule 2, the {@code DAY_OF_WEEK}, an invariant when changing the {@code WEEK_OF_MONTH}, is set to Tuesday, the closest possible value to Sunday (where Sunday is the first day of the week).
Usage model. To motivate the behavior of {@code add()} and {@code roll()}, consider a user interface component with increment and decrement buttons for the month, day, and year, and an underlying {@code GregorianCalendar}. If the interface reads January 31, 1999 and the user presses the month increment button, what should it read? If the underlying implementation uses {@code set()}, it might read March 3, 1999. A better result would be February 28, 1999. Furthermore, if the user presses the month increment button again, it should read March 31, 1999, not March 28, 1999. By saving the original date and using either {@code add()} or {@code roll()}, depending on whether larger fields should be affected, the user interface can behave as most users will intuitively expect.
Note: You should always use {@code roll} and {@code add} rather than attempting to perform arithmetic operations directly on the fields of a Calendar. It is quite possible for Calendar subclasses to have fields with non-linear behavior, for example missing months or days during non-leap years. The subclasses' add and roll methods will take this into account, while simple arithmetic manipulations may give invalid results.
| Field Summary | ||
|---|---|---|
| protected boolean | areFieldsSet | Set to {@code true} when the calendar fields have been set from the time, set to {@code false} when a field is changed and the fields must be recomputed. |
| protected int[] | fields | An integer array of calendar fields. The length is {@code FIELD_COUNT}. |
| protected boolean[] | isSet | A boolean array. Each element indicates if the corresponding field has been set. The length is {@code FIELD_COUNT}. |
| protected boolean | isTimeSet | Set to {@code true} when the time has been set, set to {@code false} when a field is changed and the time must be recomputed. |
| public static final int | ALL_STYLES | A specifier for all styles.
|
| public static final int | SHORT | A specifier for a short name
|
| public static final int | LONG | A specifier for a long name
|
| protected long | time | The time in milliseconds since January 1, 1970. |
| int | serialVersionOnStream | The version of the serialized data of the class |
| transient int | lastTimeFieldSet | |
| transient int | lastDateFieldSet | |
| public static final int | JANUARY | Value of the {@code MONTH} field indicating the first month of the year. |
| public static final int | FEBRUARY | Value of the {@code MONTH} field indicating the second month of the year. |
| public static final int | MARCH | Value of the {@code MONTH} field indicating the third month of the year. |
| public static final int | APRIL | Value of the {@code MONTH} field indicating the fourth month of the year. |
| public static final int | MAY | Value of the {@code MONTH} field indicating the fifth month of the year. |
| public static final int | JUNE | Value of the {@code MONTH} field indicating the sixth month of the year. |
| public static final int | JULY | Value of the {@code MONTH} field indicating the seventh month of the year. |
| public static final int | AUGUST | Value of the {@code MONTH} field indicating the eighth month of the year. |
| public static final int | SEPTEMBER | Value of the {@code MONTH} field indicating the ninth month of the year. |
| public static final int | OCTOBER | Value of the {@code MONTH} field indicating the tenth month of the year. |
| public static final int | NOVEMBER | Value of the {@code MONTH} field indicating the eleventh month of the year. |
| public static final int | DECEMBER | Value of the {@code MONTH} field indicating the twelfth month of the year. |
| public static final int | UNDECIMBER | Value of the {@code MONTH} field indicating the thirteenth month of the year. Although {@code GregorianCalendar} does not use this value, lunar calendars do. |
| public static final int | SUNDAY | Value of the {@code DAY_OF_WEEK} field indicating Sunday. |
| public static final int | MONDAY | Value of the {@code DAY_OF_WEEK} field indicating Monday. |
| public static final int | TUESDAY | Value of the {@code DAY_OF_WEEK} field indicating Tuesday. |
| public static final int | WEDNESDAY | Value of the {@code DAY_OF_WEEK} field indicating Wednesday. |
| public static final int | THURSDAY | Value of the {@code DAY_OF_WEEK} field indicating Thursday. |
| public static final int | FRIDAY | Value of the {@code DAY_OF_WEEK} field indicating Friday. |
| public static final int | SATURDAY | Value of the {@code DAY_OF_WEEK} field indicating Saturday. |
| public static final int | ERA | Field number for {@code get} and {@code set} indicating the
era, e.g., AD or BC in the Julian calendar. This is a calendar-specific
value; see subclass documentation.
|
| public static final int | YEAR | Field number for {@code get} and {@code set} indicating the year. This is a calendar-specific value; see subclass documentation. |
| public static final int | MONTH | Field number for {@code get} and {@code set} indicating the month. This is a calendar-specific value. The first month of the year is {@code JANUARY}; the last depends on the number of months in a year. |
| public static final int | WEEK_OF_YEAR | Field number for {@code get} and {@code set} indicating the week number within the current year. The first week of the year, as defined by {@code getFirstDayOfWeek()} and {@code getMinimalDaysInFirstWeek()}, has value 1. Subclasses define the value of {@code WEEK_OF_YEAR} for days before the first week of the year. |
| public static final int | WEEK_OF_MONTH | Field number for {@code get} and {@code set} indicating the week number within the current month. The first week of the month, as defined by {@code getFirstDayOfWeek()} and {@code getMinimalDaysInFirstWeek()}, has value 1. Subclasses define the value of {@code WEEK_OF_MONTH} for days before the first week of the month. |
| public static final int | DATE | Field number for {@code get} and {@code set} indicating the
day of the month. This is a synonym for {@code DAY_OF_MONTH}. The
first day of the month has value 1.
|
| public static final int | DAY_OF_MONTH | Field number for {@code get} and {@code set} indicating the
day of the month. This is a synonym for {@code DATE}. The first
day of the month has value 1.
|
| public static final int | DAY_OF_YEAR | Field number for {@code get} and {@code set} indicating the day number within the current year. The first day of the year has value 1. |
| public static final int | DAY_OF_WEEK | Field number for {@code get} and {@code set} indicating the day of the week. This field takes values {@code SUNDAY}, {@code MONDAY}, {@code TUESDAY}, {@code WEDNESDAY}, {@code THURSDAY}, {@code FRIDAY}, and {@code SATURDAY}. |
| public static final int | DAY_OF_WEEK_IN_MONTH | Field number for {@code get} and {@code set} indicating the
ordinal number of the day of the week within the current month. Together
with the {@code DAY_OF_WEEK} field, this uniquely specifies a day
within a month. Unlike {@code WEEK_OF_MONTH} and
{@code WEEK_OF_YEAR}, this field's value does not
depend on {@code getFirstDayOfWeek()} or
{@code getMinimalDaysInFirstWeek()}. {@code DAY_OF_MONTH 1}
through {@code 7} always correspond to DAY_OF_WEEK_IN_MONTH
1;
{@code 8} through {@code 15} correspond to
{@code DAY_OF_WEEK_IN_MONTH 2}, and so on.
{@code DAY_OF_WEEK_IN_MONTH 0} indicates the week before
{@code DAY_OF_WEEK_IN_MONTH 1}. Negative values count back from
the end of the month, so the last Sunday of a month is specified as
{@code DAY_OF_WEEK = SUNDAY, DAY_OF_WEEK_IN_MONTH = -1}. Because
negative values count backward they will usually be aligned differently
within the month than positive values. For example, if a month has 31
days, {@code DAY_OF_WEEK_IN_MONTH -1} will overlap
{@code DAY_OF_WEEK_IN_MONTH 5} and the end of {@code 4}.
|
| public static final int | AM_PM | Field number for {@code get} and {@code set} indicating whether the {@code HOUR} is before or after noon. E.g., at 10:04:15.250 PM the {@code AM_PM} is {@code PM}. |
| public static final int | HOUR | Field number for {@code get} and {@code set} indicating the
hour of the morning or afternoon. {@code HOUR} is used for the
12-hour clock. E.g., at 10:04:15.250 PM the {@code HOUR} is 10.
|
| public static final int | HOUR_OF_DAY | Field number for {@code get} and {@code set} indicating the
hour of the day. {@code HOUR_OF_DAY} is used for the 24-hour
clock. E.g., at 10:04:15.250 PM the {@code HOUR_OF_DAY} is 22.
|
| public static final int | MINUTE | Field number for {@code get} and {@code set} indicating the minute within the hour. E.g., at 10:04:15.250 PM the {@code MINUTE} is 4. |
| public static final int | SECOND | Field number for {@code get} and {@code set} indicating the second within the minute. E.g., at 10:04:15.250 PM the {@code SECOND} is 15. |
| public static final int | MILLISECOND | Field number for {@code get} and {@code set} indicating the millisecond within the second. E.g., at 10:04:15.250 PM the {@code MILLISECOND} is 250. |
| public static final int | ZONE_OFFSET | Field number for {@code get} and {@code set} indicating the raw offset from GMT in milliseconds. |
| public static final int | DST_OFFSET | Field number for {@code get} and {@code set} indicating the daylight savings offset in milliseconds. |
| public static final int | FIELD_COUNT | This is the total number of fields in this calendar. |
| public static final int | AM | Value of the {@code AM_PM} field indicating the period of the day from midnight to just before noon. |
| public static final int | PM | Value of the {@code AM_PM} field indicating the period of the day from noon to just before midnight. |
| Constructor: |
|---|
|
|
|
| Method from java.util.Calendar Summary: |
|---|
| add, after, before, clear, clear, clone, compareTo, complete, computeFields, computeTime, equals, get, getActualMaximum, getActualMinimum, getAvailableLocales, getDisplayName, getDisplayNames, getFirstDayOfWeek, getGreatestMinimum, getInstance, getInstance, getInstance, getInstance, getLeastMaximum, getMaximum, getMinimalDaysInFirstWeek, getMinimum, getTime, getTimeInMillis, getTimeZone, hashCode, internalGet, isLenient, isSet, roll, roll, set, set, set, set, setFirstDayOfWeek, setLenient, setMinimalDaysInFirstWeek, setTime, setTimeInMillis, setTimeZone, toString |
| Methods from java.lang.Object: |
|---|
| clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method from java.util.Calendar Detail: |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|