Calendar is an abstract base class for converting between a Date object and a set of integer fields such as YEAR, MONTH, DAY, HOUR, and so on. (A Date object represents a specific instant in time with millisecond precision. See Date for information about the Date class.) Subclasses of Calendar interpret a Date according to the rules of a specific calendar system. The platform provides one concrete subclass of Calendar: GregorianCalendar. Future subclasses could represent the various types of lunar calendars in use in many parts of the world.
Like other locale-sensitive classes, Calendar provides a class method, getInstance, for getting a generally useful object of this type. Calendar's getInstance method returns a Calendar object whose time fields have been initialized with the current date and time:
Calendar rightNow = Calendar.getInstance();
A 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). 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 MONTH == JANUARY for all calendars. Other values are defined by the concrete subclass, such as ERA and YEAR. See individual field documentation and subclass documentation for details.
When a Calendar is lenient, it accepts a wider range of field values than it produces. For example, a lenient GregorianCalendar interprets MONTH == JANUARY, DAY_OF_MONTH == 32 as February 1. A non-lenient GregorianCalendar throws an exception when given out-of-range field settings. When calendars recompute field values for return by get(), they normalize them. For example, a GregorianCalendar always produces DAY_OF_MONTH values between 1 and the length of the month.
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 Calendar is constructed. They may also be specified explicitly through the API.
When setting or getting the WEEK_OF_MONTH or WEEK_OF_YEAR fields, 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 getFirstDayOfWeek() and containing at least 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 get() may be different. For example, a specific Calendar subclass may designate the week before week 1 of a year as week n of the previous year.
When computing a Date from time fields, two special circumstances may arise: there may be insufficient information to compute the 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: for some non-Gregorian calendars, different fields may be necessary for complete disambiguation. For example, a full specification of the historical Arabic astronomical calendar requires year, month, day-of-month and day-of-week in some cases.
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 DateFormat to format dates.
Field manipulation methods
Calendar fields can be changed using three methods: set(), add(), and roll().
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
fafter the call minus the value of fieldfbefore the call isdelta, modulo any overflow that has occurred in fieldf. 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
fis 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.HOURis a smaller field thanDAY_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.
roll(f, delta) adds delta to field f without changing larger fields. This is equivalent to calling 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.
DAY_OF_MONTHis a larger field thanHOUR.
Example: See int).
Usage model. To motivate the behavior of add() and roll(), consider a user interface component with increment and decrement buttons for the month, day, and year, and an underlying 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 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 add() or roll(), depending on whether larger fields should be affected, the user interface can behave as most users will intuitively expect.
| Field Detail |
public static final int ERA
get and 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
get and set indicating the year. This is a calendar-specific value; see subclass documentation.public static final int MONTH
get and set indicating the month. This is a calendar-specific value. The first month of the year is JANUARY which is 0; the last depends on the number of months in a year.public static final int WEEK_OF_YEAR
get and set indicating the week number within the current year. The first week of the year, as defined by getFirstDayOfWeek() and getMinimalDaysInFirstWeek(), has value 1. Subclasses define the value of WEEK_OF_YEAR for days before the first week of the year.public static final int WEEK_OF_MONTH
get and set indicating the week number within the current month. The first week of the month, as defined by getFirstDayOfWeek() and getMinimalDaysInFirstWeek(), has value 1. Subclasses define the value of WEEK_OF_MONTH for days before the first week of the month.public static final int DATE
get and set indicating the day of the month. This is a synonym for DAY_OF_MONTH. The first day of the month has value 1.public static final int DAY_OF_MONTH
get and set indicating the day of the month. This is a synonym for DATE. The first day of the month has value 1.public static final int DAY_OF_YEAR
get and 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
get and set indicating the day of the week. This field takes values SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, and SATURDAY.public static final int DAY_OF_WEEK_IN_MONTH
get and set indicating the ordinal number of the day of the week within the current month. Together with the DAY_OF_WEEK field, this uniquely specifies a day within a month. Unlike WEEK_OF_MONTH and WEEK_OF_YEAR, this field's value does not depend on getFirstDayOfWeek() or getMinimalDaysInFirstWeek(). DAY_OF_MONTH 1 through 7 always correspond to DAY_OF_WEEK_IN_MONTH 1; 8 through 14 correspond to DAY_OF_WEEK_IN_MONTH 2, and so on. DAY_OF_WEEK_IN_MONTH 0 indicates the week before 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 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, DAY_OF_WEEK_IN_MONTH -1 will overlap DAY_OF_WEEK_IN_MONTH 5 and the end of 4.public static final int AM_PM
get and set indicating whether the HOUR is before or after noon. E.g., at 10:04:15.250 PM the AM_PM is PM.public static final int HOUR
get and set indicating the hour of the morning or afternoon. HOUR is used for the 12-hour clock. E.g., at 10:04:15.250 PM the HOUR is 10.public static final int HOUR_OF_DAY
get and set indicating the hour of the day. HOUR_OF_DAY is used for the 24-hour clock. E.g., at 10:04:15.250 PM the HOUR_OF_DAY is 22.public static final int MINUTE
get and set indicating the minute within the hour. E.g., at 10:04:15.250 PM the MINUTE is 4.public static final int SECOND
get and set indicating the second within the minute. E.g., at 10:04:15.250 PM the SECOND is 15.public static final int MILLISECOND
get and set indicating the millisecond within the second. E.g., at 10:04:15.250 PM the MILLISECOND is 250.public static final int ZONE_OFFSET
get and set indicating the raw offset from GMT in milliseconds. This field reflects the correct GMT offset value of the time zone of this Calendar if the TimeZone implementation subclass supports historical GMT offset changes.
public static final int DST_OFFSET
get and set indicating the daylight savings offset in milliseconds. This field reflects the correct daylight saving offset value of the time zone of this Calendar if the TimeZone implementation subclass supports historical Daylight Saving Time schedule changes.
public static final int FIELD_COUNT
get and set. Field numbers range from 0..FIELD_COUNT-1.public static final int SUNDAY
DAY_OF_WEEK field indicating Sunday.public static final int MONDAY
DAY_OF_WEEK field indicating Monday.public static final int TUESDAY
DAY_OF_WEEK field indicating Tuesday.public static final int WEDNESDAY
DAY_OF_WEEK field indicating Wednesday.public static final int THURSDAY
DAY_OF_WEEK field indicating Thursday.public static final int FRIDAY
DAY_OF_WEEK field indicating Friday.public static final int SATURDAY
DAY_OF_WEEK field indicating Saturday.public static final int JANUARY
MONTH field indicating the first month of the year.public static final int FEBRUARY
MONTH field indicating the second month of the year.public static final int MARCH
MONTH field indicating the third month of the year.public static final int APRIL
MONTH field indicating the fourth month of the year.public static final int MAY
MONTH field indicating the fifth month of the year.public static final int JUNE
MONTH field indicating the sixth month of the year.public static final int JULY
MONTH field indicating the seventh month of the year.public static final int AUGUST
MONTH field indicating the eighth month of the year.public static final int SEPTEMBER
MONTH field indicating the ninth month of the year.public static final int OCTOBER
MONTH field indicating the tenth month of the year.public static final int NOVEMBER
MONTH field indicating the eleventh month of the year.public static final int DECEMBER
MONTH field indicating the twelfth month of the year.public static final int UNDECIMBER
MONTH field indicating the thirteenth month of the year. Although GregorianCalendar does not use this value, lunar calendars do.public static final int AM
AM_PM field indicating the period of the day from midnight to just before noon.public static final int PM
AM_PM field indicating the period of the day from noon to just before midnight.protected int[] fields
FIELD_COUNT integers, with index values ERA through DST_OFFSET.protected boolean[] isSet
FIELD_COUNT booleans, with index values ERA through DST_OFFSET.transient int[] stamp
protected long time
protected boolean isTimeSet
time is valid. The time is made invalid by a change to an item of field[].protected boolean areFieldsSet
fields[] are in sync with the currently set time. If false, then the next attempt to get the value of a field will force a recomputation of all fields from the current value of time.transient boolean areAllFieldsSet
private boolean lenient
time from fields[].private java.util.TimeZone zone
TimeZone used by this calendar. Calendar uses the time zone data to translate between locale and GMT time.private int firstDayOfWeek
SUNDAY, MONDAY, etc. This is a locale-dependent value.private int minimalDaysInFirstWeek
private static java.util.Hashtable cachedLocaleData
private int nextStamp
stamp[], an internal array. This actually should not be written out to the stream, and will probably be removed from the stream in the near future. In the meantime, a value of MINIMUM_USER_STAMP should be used.private int serialVersionOnStream
serialVersionOnStream is written.| Constructor Detail |
protected Calendar()
protected Calendar(java.util.TimeZone zone,
java.util.Locale aLocale)
zone - the time zone to useaLocale - the locale for the week data| Method Detail |
public static java.util.Calendar getInstance()
Calendar returned is based on the current time in the default time zone with the default locale.public static java.util.Calendar getInstance(java.util.TimeZone zone)
Calendar returned is based on the current time in the given time zone with the default locale.zone - the time zone to usepublic static java.util.Calendar getInstance(java.util.Locale aLocale)
Calendar returned is based on the current time in the default time zone with the given locale.aLocale - the locale for the week data
public static java.util.Calendar getInstance(java.util.TimeZone zone,
java.util.Locale aLocale)
Calendar returned is based on the current time in the given time zone with the given locale.zone - the time zone to useaLocale - the locale for the week datapublic static synchronized java.util.Locale[] getAvailableLocales()
protected abstract void computeTime()
fields[] to the millisecond time value time.protected abstract void computeFields()
time to field values in fields[]. This allows you to sync up the time field values with a new time that is set for the calendar. The time is not recomputed first; to recompute the time, then the fields, call the complete method.public final java.util.Date getTime()
public final void setTime(java.util.Date date)
Note: Calling setTime() with Date(Long.MAX_VALUE) or Date(Long.MIN_VALUE) may yield incorrect field values from get().
date - the given Date.public long getTimeInMillis()
public void setTimeInMillis(long millis)
millis - the new time in UTC milliseconds from the epoch.public int get(int field)
field - the given time field.ArrayIndexOutOfBoundsException - if specified field is out of range (field < 0 || field >= FIELD_COUNT).protected final int internalGet(int field)
field - the given time field.
final void internalSet(int field,
int value)
final void internalClear(int field)
field - the given calendar field.ArrayIndexOutOfBoundsException - if specified field is out of range (field < 0 || field >= FIELD_COUNT).
public void set(int field,
int value)
field - the given time field.value - the value to be set for the given time field.ArrayIndexOutOfBoundsException - if specified field is out of range (field < 0 || field >= FIELD_COUNT).
public final void set(int year,
int month,
int date)
clear first.year - the value used to set the YEAR time field.month - the value used to set the MONTH time field. Month value is 0-based. e.g., 0 for January.date - the value used to set the DATE time field.
public final void set(int year,
int month,
int date,
int hour,
int minute)
clear first.year - the value used to set the YEAR time field.month - the value used to set the MONTH time field. Month value is 0-based. e.g., 0 for January.date - the value used to set the DATE time field.hour - the value used to set the HOUR_OF_DAY time field.minute - the value used to set the MINUTE time field.
public final void set(int year,
int month,
int date,
int hour,
int minute,
int second)
clear first.year - the value used to set the YEAR time field.month - the value used to set the MONTH time field. Month value is 0-based. e.g., 0 for January.date - the value used to set the DATE time field.hour - the value used to set the HOUR_OF_DAY time field.minute - the value used to set the MINUTE time field.second - the value used to set the SECOND time field.public final void clear()
public final void clear(int field)
field - the time field to be cleared.public final boolean isSet(int field)
protected void complete()
public boolean equals(java.lang.Object obj)
true if and only if the argument is not null and is a Calendar object that represents the same calendar as this object.obj - the object to compare with.true if the objects are the same; false otherwise.public int hashCode()
public boolean before(java.lang.Object when)
when - the Calendar to be compared with this Calendar.public boolean after(java.lang.Object when)
when - the Calendar to be compared with this Calendar.
public abstract void add(int field,
int amount)
add(Calendar.DATE, -5).
field - the time field.amount - the amount of date or time to be added to the field.
public abstract void roll(int field,
boolean up)
roll(Calendar.DATE, true). When rolling on the year or Calendar.YEAR field, it will roll the year value in the range between 1 and the value returned by calling getMaximum(Calendar.YEAR). When rolling on the month or Calendar.MONTH field, other fields like date might conflict and, need to be changed. For instance, rolling the month on the date 01/31/96 will result in 02/29/96. When rolling on the hour-in-day or Calendar.HOUR_OF_DAY field, it will roll the hour value in the range between 0 and 23, which is zero-based.
field - the time field.up - indicates if the value of the specified time field is to be rolled up or rolled down. Use true if rolling up, false otherwise.
public void roll(int field,
int amount)
field - the time field.amount - the signed amount to add to field.public void setTimeZone(java.util.TimeZone value)
value - the given time zone.public java.util.TimeZone getTimeZone()
public void setLenient(boolean lenient)
public boolean isLenient()
public void setFirstDayOfWeek(int value)
value - the given first day of the week.public int getFirstDayOfWeek()
public void setMinimalDaysInFirstWeek(int value)
value - the given minimal days required in the first week of the year.public int getMinimalDaysInFirstWeek()
public abstract int getMinimum(int field)
field - the given time field.public abstract int getMaximum(int field)
field - the given time field.public abstract int getGreatestMinimum(int field)
field - the given time field.public abstract int getLeastMaximum(int field)
field - the given time field.public int getActualMinimum(int field)
field - the field to determine the minimum ofpublic int getActualMaximum(int field)
field - the field to determine the maximum ofpublic java.lang.Object clone()
public java.lang.String toString()
null.private void setWeekCountData(java.util.Locale desiredLocale)
desiredLocale - the given locale.private void updateTime()
private final void adjustStamp()
private void invalidateWeekFields()
private void writeObject(java.io.ObjectOutputStream stream)
Calendar would only write out its state data and the current time, and not write any field data out, such as fields[], isTimeSet, areFieldsSet, and isSet[]. nextStamp also should not be part of the persistent state. Unfortunately, this didn't happen before JDK 1.1 shipped. To be compatible with JDK 1.1, we will always have to write out the field values and state flags. However, nextStamp can be removed from the serialization stream; this will probably happen in the near future.private void readObject(java.io.ObjectInputStream stream)