Calendar

Kotlin |Java

abstract class Calendar : Serializable, Cloneable, Comparable<Calendar!>

kotlin.Any
↳	android.icu.util.Calendar

Known Direct Subclasses

ChineseCalendar, CopticCalendar, EthiopicCalendar, GregorianCalendar, HebrewCalendar, IndianCalendar, IslamicCalendar

ChineseCalendar	`ChineseCalendar` is a concrete subclass of `Calendar` that implements a traditional Chinese calendar.
CopticCalendar	Implement the Coptic calendar system.
EthiopicCalendar	Implement the Ethiopic calendar system.
GregorianCalendar	[icu enhancement] ICU's replacement for `java.util.GregorianCalendar`.
HebrewCalendar	`HebrewCalendar` is a subclass of `Calendar` that that implements the traditional Hebrew calendar.
IndianCalendar	`IndianCalendar` is a subclass of `GregorianCalendar` that numbers years since the birth of the Buddha.
IslamicCalendar	`IslamicCalendar` is a subclass of `Calendar` that that implements the Islamic civil and religious calendars.

Known Indirect Subclasses

BuddhistCalendar, JapaneseCalendar, TaiwanCalendar

BuddhistCalendar	`BuddhistCalendar` is a subclass of `GregorianCalendar` that numbers years since the birth of the Buddha.
JapaneseCalendar	`JapaneseCalendar` is a subclass of `GregorianCalendar` that numbers years and eras based on the reigns of the Japanese emperors.
TaiwanCalendar	`TaiwanCalendar` is a subclass of `GregorianCalendar` that numbers years since 1912.

[icu enhancement] ICU's replacement for java.util.Calendar. Methods, fields, and other functionality specific to ICU are labeled '[icu]'.

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. ICU4J contains several subclasses implementing different international calendar systems.

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 of a type appropriate to the locale, whose time fields have been initialized with the current date and time:

Calendar rightNow = Calendar.getInstance()

When a ULocale is used by getInstance, its 'calendar' tag and value are retrieved if present. If a recognized value is supplied, a calendar is provided and configured as appropriate. Currently recognized tags are "buddhist", "chinese", "coptic", "ethiopic", "gregorian", "hebrew", "islamic", "islamic-civil", "japanese", and "roc". For example:

Calendar cal = Calendar.getInstance(new ULocale("en_US@calendar=japanese"));

will return an instance of JapaneseCalendar (using en_US conventions for minimum days in first week, start day of week, et cetera).

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, some 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), there may be inconsistent information (such as "Tuesday, July 15, 1996" -- July 15, 1996 is actually a Monday), or the input time might be ambiguous because of time zone transition.

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.

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

For the time of day:

HOUR_OF_DAY
  AM_PM + HOUR

Ambiguous Wall Clock Time. When time offset from UTC has changed, it produces an ambiguous time slot around the transition. For example, many US locations observe daylight saving time. On the date switching to daylight saving time in US, wall clock time jumps from 12:59 AM (standard) to 2:00 AM (daylight). Therefore, wall clock time from 1:00 AM to 1:59 AM do not exist on the date. When the input wall time fall into this missing time slot, the ICU Calendar resolves the time using the UTC offset before the transition by default. In this example, 1:30 AM is interpreted as 1:30 AM standard time (non-exist), so the final result will be 2:30 AM daylight time.

On the date switching back to standard time, wall clock time is moved back one hour at 2:00 AM. So wall clock time from 1:00 AM to 1:59 AM occur twice. In this case, the ICU Calendar resolves the time using the UTC offset after the transition by default. For example, 1:30 AM on the date is resolved as 1:30 AM standard time.

Ambiguous wall clock time resolution behaviors can be customized by Calendar APIs setRepeatedWallTimeOption(int) and setSkippedWallTimeOption(int). These methods are available in ICU 49 or later versions.

Note: for some non-Gregorian calendars, different fields may be necessary for complete disambiguation. For example, a full specification of the historial 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:

24:00:00 "belongs" to the following day. That is, 23:59 on Dec 31, 1969 < 24:00 on Jan 1, 1970 < 24:01:00 on Jan 1, 1970
Although historically not precise, midnight also belongs to "am", and noon belongs to "pm", so on the same day, 12:00 am (midnight) < 12:01 am, and 12:00 pm (noon) < 12:01 pm

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 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.

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_MONTH is a larger field than HOUR.

Example: Consider a GregorianCalendar originally set to August 31, 1999. Calling roll(Calendar.MONTH, 8) sets the calendar to April 30, 1999. Add rule 1 sets the MONTH field to April. Using a GregorianCalendar, the 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 YEAR field value of 1999.

Example: Consider a GregorianCalendar originally set to Sunday June 6, 1999. Calling roll(Calendar.WEEK_OF_MONTH, -1) sets the calendar to Tuesday June 1, 1999, whereas calling 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 MONTH must not change when the 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 DAY_OF_WEEK, an invariant when changing the 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 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.

Note: You should always use #roll and 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.

Calendar Architecture in ICU4J

Recently the implementation of Calendar has changed significantly in order to better support subclassing. The original Calendar class was designed to support subclassing, but it had only one implemented subclass, GregorianCalendar. With the implementation of several new calendar subclasses, including the BuddhistCalendar, ChineseCalendar, HebrewCalendar, IslamicCalendar, and JapaneseCalendar, the subclassing API has been reworked thoroughly. This section details the new subclassing API and other ways in which android.icu.util.Calendar differs from java.util.Calendar.

Changes

Overview of changes between the classic Calendar architecture and the new architecture.

The fields[] array is private now instead of protected. Subclasses must access it using the methods internalSet and #internalGet. Motivation: Subclasses should not directly access data members.
The time long word is private now instead of protected. Subclasses may access it using the method internalGetTimeInMillis, which does not provoke an update. Motivation: Subclasses should not directly access data members.
The scope of responsibility of subclasses has been drastically reduced. As much functionality as possible is implemented in the Calendar base class. As a result, it is much easier to subclass Calendar. Motivation: Subclasses should not have to reimplement common code. Certain behaviors are common across calendar systems: The definition and behavior of week-related fields and time fields, the arithmetic (add and roll) behavior of many fields, and the field validation system.
The subclassing API has been completely redesigned.
The Calendar base class contains some Gregorian calendar algorithmic support that subclasses can use (specifically in handleComputeFields). Subclasses can use the methods getGregorianXxx() to obtain precomputed values. Motivation: This is required by all Calendar subclasses in order to implement consistent time zone behavior, and Gregorian-derived systems can use the already computed data.
The FIELD_COUNT constant has been removed. Use getFieldCount. In addition, framework API has been added to allow subclasses to define additional fields. Motivation: The number of fields is not constant across calendar systems.
The range of handled dates has been narrowed from +/- ~300,000,000 years to +/- ~5,000,000 years. In practical terms this should not affect clients. However, it does mean that client code cannot be guaranteed well-behaved results with dates such as Date(Long.MIN_VALUE) or Date(Long.MAX_VALUE). Instead, the Calendar protected constants should be used. Motivation: With the addition of the JULIAN_DAY field, Julian day numbers must be restricted to a 32-bit int. This restricts the overall supported range. Furthermore, restricting the supported range simplifies the computations by removing special case code that was used to accommodate arithmetic overflow at millis near Long.MIN_VALUE and Long.MAX_VALUE.
New fields are implemented: JULIAN_DAY defines single-field specification of the date. MILLISECONDS_IN_DAY defines a single-field specification of the wall time. DOW_LOCAL and YEAR_WOY implement localized day-of-week and week-of-year behavior.
Subclasses can access protected millisecond constants defined in Calendar.
New API has been added to support calendar-specific subclasses of DateFormat.
Several subclasses have been implemented, representing various international calendar systems.

Subclass API

The original Calendar API was based on the experience of implementing a only a single subclass, GregorianCalendar. As a result, all of the subclassing kinks had not been worked out. The new subclassing API has been refined based on several implemented subclasses. This includes methods that must be overridden and methods for subclasses to call. Subclasses no longer have direct access to fields and stamp. Instead, they have new API to access these. Subclasses are able to allocate the fields array through a protected framework method; this allows subclasses to specify additional fields.

More functionality has been moved into the base class. The base class now contains much of the computational machinery to support the Gregorian calendar. This is based on two things: (1) Many calendars are based on the Gregorian calendar (such as the Buddhist and Japanese imperial calendars). (2) All calendars require basic Gregorian support in order to handle timezone computations.

Common computations have been moved into Calendar. Subclasses no longer compute the week related fields and the time related fields. These are commonly handled for all calendars by the base class.

Subclass computation of time => fields

The ERA, YEAR, EXTENDED_YEAR, MONTH, DAY_OF_MONTH, and DAY_OF_YEAR fields are computed by the subclass, based on the Julian day. All other fields are computed by Calendar.

Subclasses should implement handleComputeFields to compute the ERA, YEAR, EXTENDED_YEAR, MONTH, DAY_OF_MONTH, and DAY_OF_YEAR fields, based on the value of the JULIAN_DAY field. If there are calendar-specific fields not defined by Calendar, they must also be computed. These are the only fields that the subclass should compute. All other fields are computed by the base class, so time and week fields behave in a consistent way across all calendars. The default version of this method in Calendar implements a proleptic Gregorian calendar. Within this method, subclasses may call getGregorianXxx() to obtain the Gregorian calendar month, day of month, and extended year for the given date.

Subclass computation of fields => time

The interpretation of most field values is handled entirely by Calendar. Calendar determines which fields are set, which are not, which are set more recently, and so on. In addition, Calendar handles the computation of the time from the time fields and handles the week-related fields. The only thing the subclass must do is determine the extended year, based on the year fields, and then, given an extended year and a month, it must return a Julian day number.

Subclasses should implement handleGetExtendedYear to return the extended year for this calendar system, based on the YEAR, EXTENDED_YEAR, and any fields that the calendar system uses that are larger than a year, such as ERA.
Subclasses should implement handleComputeMonthStart to return the Julian day number associated with a month and extended year. This is the Julian day number of the day before the first day of the month. The month number is zero-based. This computation should not depend on any field values.

Other methods

Subclasses should implement handleGetMonthLength to return the number of days in a given month of a given extended year. The month number, as always, is zero-based.
Subclasses should implement handleGetYearLength to return the number of days in the given extended year. This method is used by computeWeekFields to compute the WEEK_OF_YEAR and YEAR_WOY fields.
Subclasses should implement handleGetLimit to return the protected values of a field, depending on the value of limitType. This method only needs to handle the fields ERA, YEAR, MONTH, WEEK_OF_YEAR, WEEK_OF_MONTH, DAY_OF_MONTH, DAY_OF_YEAR, DAY_OF_WEEK_IN_MONTH, YEAR_WOY, and EXTENDED_YEAR. Other fields are invariant (with respect to calendar system) and are handled by the base class.
Optionally, subclasses may override #validateField to check any subclass-specific fields. If the field's value is out of range, the method should throw an IllegalArgumentException. The method may call super.validateField(field) to handle fields in a generic way, that is, to compare them to the range getMinimum(field)..getMaximum(field).
Optionally, subclasses may override handleCreateFields to create an int[] array large enough to hold the calendar's fields. This is only necessary if the calendar defines additional fields beyond those defined by Calendar. The length of the result must be be between the base and maximum field counts.
Optionally, subclasses may override #handleGetDateFormat to create a DateFormat appropriate to this calendar. This is only required if a calendar subclass redefines the use of a field (for example, changes the ERA field from a symbolic field to a numeric one) or defines an additional field.
Optionally, subclasses may override #roll and add to handle fields that are discontinuous. For example, in the Hebrew calendar the month "Adar I" only occurs in leap years; in other years the calendar jumps from Shevat (month #4) to Adar (month #6). The HebrewCalendar.add and android.icu.util.HebrewCalendar#roll methods take this into account, so that adding 1 month to Shevat gives the proper result (Adar) in a non-leap year. The protected utility method pinField is often useful when implementing these two methods.

Normalized behavior

The behavior of certain fields has been made consistent across all calendar systems and implemented in Calendar.

Time is normalized. Even though some calendar systems transition between days at sunset or at other times, all ICU4J calendars transition between days at local zone midnight. This allows ICU4J to centralize the time computations in Calendar and to maintain basic correspondences between calendar systems. Affected fields: AM_PM, HOUR, HOUR_OF_DAY, MINUTE, SECOND, MILLISECOND, ZONE_OFFSET, and DST_OFFSET.
DST behavior is normalized. Daylight savings time behavior is computed the same for all calendar systems, and depends on the value of several GregorianCalendar fields: the YEAR, MONTH, and DAY_OF_MONTH. As a result, Calendar always computes these fields, even for non-Gregorian calendar systems. These fields are available to subclasses.
Weeks are normalized. Although locales define the week differently, in terms of the day on which it starts, and the designation of week number one of a month or year, they all use a common mechanism. Furthermore, the day of the week has a simple and consistent definition throughout history. For example, although the Gregorian calendar introduced a discontinuity when first instituted, the day of week was not disrupted. For this reason, the fields DAY_OF_WEEK, WEEK_OF_YEAR, WEEK_OF_MONTH, DAY_OF_WEEK_IN_MONTH, DOW_LOCAL, YEAR_WOY are all computed in a consistent way in the base class, based on the EXTENDED_YEAR, DAY_OF_YEAR, MONTH, and DAY_OF_MONTH, which are computed by the subclass.

Supported range

The allowable range of Calendar has been narrowed. GregorianCalendar used to attempt to support the range of dates with millisecond values from Long.MIN_VALUE to Long.MAX_VALUE. This introduced awkward constructions (hacks) which slowed down performance. It also introduced non-uniform behavior at the boundaries. The new Calendar protocol specifies the maximum range of supportable dates as those having Julian day numbers of -0x7F000000 to +0x7F000000. This corresponds to years from ~5,800,000 BCE to ~5,800,000 CE. Programmers should use the protected constants in Calendar to specify an extremely early or extremely late date.

General notes

Calendars implementations are proleptic. For example, even though the Gregorian calendar was not instituted until the 16th century, the GregorianCalendar class supports dates before the historical onset of the calendar by extending the calendar system backward in time. Similarly, the HebrewCalendar extends backward before the start of its epoch into zero and negative years. Subclasses do not throw exceptions because a date precedes the historical start of a calendar system. Instead, they implement handleGetLimit to return appropriate limits on YEAR, ERA, etc. fields. Then, if the calendar is set to not be lenient, out-of-range field values will trigger an exception.
Calendar system subclasses compute a extended year. This differs from the YEAR field in that it ranges over all integer values, including zero and negative values, and it encapsulates the information of the YEAR field and all larger fields. Thus, for the Gregorian calendar, the EXTENDED_YEAR is computed as ERA==AD ? YEAR : 1-YEAR. Another example is the Mayan long count, which has years (KUN) and nested cycles of years (KATUN and BAKTUN). The Mayan EXTENDED_YEAR is computed as TUN + 20 * (KATUN + 20 * BAKTUN). The Calendar base class uses the EXTENDED_YEAR field to compute the week-related fields.

Summary

Nested classes
	`WeekData` Simple, immutable struct-like class for access to the CLDR week data.

Constants
static Int	`AM` Value of the `AM_PM` field indicating the period of the day from midnight to just before noon.
static Int	`AM_PM` Field number for `get` and `set` indicating whether the `HOUR` is before or after noon.
static Int	`APRIL` Value of the `MONTH` field indicating the fourth month of the year.
static Int	`AUGUST` Value of the `MONTH` field indicating the eighth month of the year.
static Int	`DATE` Field number for `get` and `set` indicating the day of the month.
static Int	`DAY_OF_MONTH` Field number for `get` and `set` indicating the day of the month.
static Int	`DAY_OF_WEEK` Field number for `get` and `set` indicating the day of the week.
static Int	`DAY_OF_WEEK_IN_MONTH` Field number for `get` and `set` indicating the ordinal number of the day of the week within the current month.
static Int	`DAY_OF_YEAR` Field number for `get` and `set` indicating the day number within the current year.
static Int	`DECEMBER` Value of the `MONTH` field indicating the twelfth month of the year.
static Int	`DOW_LOCAL` [icu] Field number for `get()` and `set()` indicating the localized day of week.
static Int	`DST_OFFSET` Field number for `get` and `set` indicating the daylight savings offset in milliseconds.
static Int	`EPOCH_JULIAN_DAY` The Julian day of the epoch, that is, January 1, 1970 on the Gregorian calendar.
static Int	`ERA` Field number for `get` and `set` indicating the era, e.
static Int	`EXTENDED_YEAR` [icu] Field number for `get()` and `set()` indicating the extended year.
static Int	`FEBRUARY` Value of the `MONTH` field indicating the second month of the year.
static Int	`FRIDAY` Value of the `DAY_OF_WEEK` field indicating Friday.
static Int	`GREATEST_MINIMUM` Limit type for `getLimit()` and `handleGetLimit()` indicating the greatest minimum value that a field can take.
static Int	`HOUR` Field number for `get` and `set` indicating the hour of the morning or afternoon.
static Int	`HOUR_OF_DAY` Field number for `get` and `set` indicating the hour of the day.
static Int	`INTERNALLY_SET` Value of the time stamp `stamp[]` indicating that a field has been set via computations from the time or from other fields.
static Int	`IS_LEAP_MONTH` [icu] Field indicating whether or not the current month is a leap month.
static Int	`JANUARY` Value of the `MONTH` field indicating the first month of the year.
static Int	`JAN_1_1_JULIAN_DAY` The Julian day of the Gregorian epoch, that is, January 1, 1 on the Gregorian calendar.
static Int	`JULIAN_DAY` [icu] Field number for `get()` and `set()` indicating the modified Julian day number.
static Int	`JULY` Value of the `MONTH` field indicating the seventh month of the year.
static Int	`JUNE` Value of the `MONTH` field indicating the sixth month of the year.
static Int	`LEAST_MAXIMUM` Limit type for `getLimit()` and `handleGetLimit()` indicating the least maximum value that a field can take.
static Int	`MARCH` Value of the `MONTH` field indicating the third month of the year.
static Int	`MAXIMUM` Limit type for `getLimit()` and `handleGetLimit()` indicating the maximum value that a field can take (greatest maximum).
static Int	`MAX_FIELD_COUNT` The maximum number of fields possible.
static Int	`MAX_JULIAN` The maximum supported Julian day.
static Long	`MAX_MILLIS` The maximum supported epoch milliseconds.
static Int	`MAY` Value of the `MONTH` field indicating the fifth month of the year.
static Int	`MILLISECOND` Field number for `get` and `set` indicating the millisecond within the second.
static Int	`MILLISECONDS_IN_DAY` [icu] Field number for `get()` and `set()` indicating the milliseconds in the day.
static Int	`MINIMUM` Limit type for `getLimit()` and `handleGetLimit()` indicating the minimum value that a field can take (least minimum).
static Int	`MINIMUM_USER_STAMP` If the time stamp `stamp[]` has a value greater than or equal to `MINIMUM_USER_SET` then it has been set by the user via a call to `set()`.
static Int	`MINUTE` Field number for `get` and `set` indicating the minute within the hour.
static Int	`MIN_JULIAN` The minimum supported Julian day.
static Long	`MIN_MILLIS` The minimum supported epoch milliseconds.
static Int	`MONDAY` Value of the `DAY_OF_WEEK` field indicating Monday.
static Int	`MONTH` Field number for `get` and `set` indicating the month.
static Int	`NOVEMBER` Value of the `MONTH` field indicating the eleventh month of the year.
static Int	`OCTOBER` Value of the `MONTH` field indicating the tenth month of the year.
static Long	`ONE_DAY` The number of milliseconds in one day.
static Int	`ONE_HOUR` The number of milliseconds in one hour.
static Int	`ONE_MINUTE` The number of milliseconds in one minute.
static Int	`ONE_SECOND` The number of milliseconds in one second.
static Long	`ONE_WEEK` The number of milliseconds in one week.
static Int	`PM` Value of the `AM_PM` field indicating the period of the day from noon to just before midnight.
static Int	`RESOLVE_REMAP` Value to OR against resolve table field values for remapping.
static Int	`SATURDAY` Value of the `DAY_OF_WEEK` field indicating Saturday.
static Int	`SECOND` Field number for `get` and `set` indicating the second within the minute.
static Int	`SEPTEMBER` Value of the `MONTH` field indicating the ninth month of the year.
static Int	`SUNDAY` Value of the `DAY_OF_WEEK` field indicating Sunday.
static Int	`THURSDAY` Value of the `DAY_OF_WEEK` field indicating Thursday.
static Int	`TUESDAY` Value of the `DAY_OF_WEEK` field indicating Tuesday.
static Int	`UNDECIMBER` Value of the `MONTH` field indicating the thirteenth month of the year.
static Int	`UNSET` Value of the time stamp `stamp[]` indicating that a field has not been set since the last call to `clear()`.
static Int	`WALLTIME_FIRST` [icu]Option used by `setRepeatedWallTimeOption(int)` and `setSkippedWallTimeOption(int)` specifying an ambiguous wall time to be interpreted as the earliest.
static Int	`WALLTIME_LAST` [icu]Option used by `setRepeatedWallTimeOption(int)` and `setSkippedWallTimeOption(int)` specifying an ambiguous wall time to be interpreted as the latest.
static Int	`WALLTIME_NEXT_VALID` [icu]Option used by `setSkippedWallTimeOption(int)` specifying an ambiguous wall time to be interpreted as the next valid wall time.
static Int	`WEDNESDAY` Value of the `DAY_OF_WEEK` field indicating Wednesday.
static Int	`WEEK_OF_MONTH` Field number for `get` and `set` indicating the week number within the current month.
static Int	`WEEK_OF_YEAR` Field number for `get` and `set` indicating the week number within the current year.
static Int	`YEAR` Field number for `get` and `set` indicating the year.
static Int	`YEAR_WOY` [icu] Field number for `get()` and `set()` indicating the extended year corresponding to the `WEEK_OF_YEAR` field.
static Int	`ZONE_OFFSET` Field number for `get` and `set` indicating the raw offset from GMT in milliseconds.

Protected constructors
`Calendar()` Constructs a Calendar with the default time zone and the default `FORMAT` locale.
`Calendar(zone: TimeZone!, aLocale: Locale!)` Constructs a calendar with the specified time zone and locale.
`Calendar(zone: TimeZone!, locale: ULocale!)` Constructs a calendar with the specified time zone and locale.

Public methods
open Unit	`add(field: Int, amount: Int)` Add a signed amount to a specified field, using this calendar's rules.
open Boolean	`after(when: Any!)` Compares the time field records.
open Boolean	`before(when: Any!)` Compares the time field records.
Unit	`clear()` Clears the values of all the time fields.
Unit	`clear(field: Int)` Clears the value in the given time field.
open Any	`clone()` Overrides Cloneable
open Int	`compareTo(other: Calendar!)` Compares the times (in millis) represented by two `Calendar` objects.
open Boolean	`equals(other: Any?)` Compares this calendar to the specified object.
open Int	`fieldDifference(when: Date!, field: Int)` [icu] Returns the difference between the given time and the time this calendar object is set to.
Int	`get(field: Int)` Returns the value for a given time field.
open Int	`getActualMaximum(field: Int)` Returns the maximum value that this field could have, given the current date.
open Int	`getActualMinimum(field: Int)` Returns the minimum value that this field could have, given the current date.
open static Array<Locale!>!	`getAvailableLocales()` Returns the list of locales for which Calendars are installed.
open DateFormat!	`getDateTimeFormat(dateStyle: Int, timeStyle: Int, loc: Locale!)` [icu] Returns a `DateFormat` appropriate to this calendar.
open DateFormat!	`getDateTimeFormat(dateStyle: Int, timeStyle: Int, loc: ULocale!)` [icu] Returns a `DateFormat` appropriate to this calendar.
open String!	`getDisplayName(loc: Locale!)` Returns the name of this calendar in the language of the given locale.
open String!	`getDisplayName(loc: ULocale!)` Returns the name of this calendar in the language of the given locale.
Int	`getFieldCount()` [icu] Returns the number of fields defined by this calendar.
open Int	`getFirstDayOfWeek()` Returns what the first day of the week is, where 1 = `SUNDAY` and 7 = `SATURDAY`.
Int	`getGreatestMinimum(field: Int)` Returns the highest minimum value for the given field if varies.
open static Calendar!	`getInstance()` Returns a calendar using the default time zone and locale.
open static Calendar!	`getInstance(zone: TimeZone!)` Returns a calendar using the specified time zone and default locale.
open static Calendar!	`getInstance(aLocale: Locale!)` Returns a calendar using the default time zone and specified locale.
open static Calendar!	`getInstance(locale: ULocale!)` Returns a calendar using the default time zone and specified locale.
open static Calendar!	`getInstance(zone: TimeZone!, aLocale: Locale!)` Returns a calendar with the specified time zone and locale.
open static Calendar!	`getInstance(zone: TimeZone!, locale: ULocale!)` Returns a calendar with the specified time zone and locale.
static Array<String!>!	`getKeywordValuesForLocale(key: String!, locale: ULocale!, commonlyUsed: Boolean)` [icu] Given a key and a locale, returns an array of string values in a preferred order that would make a difference.
Int	`getLeastMaximum(field: Int)` Returns the lowest maximum value for the given field if varies.
Int	`getMaximum(field: Int)` Returns the maximum value for the given time field.
open Int	`getMinimalDaysInFirstWeek()` Returns what the minimal days required in the first week of the year are.
Int	`getMinimum(field: Int)` Returns the minimum value for the given time field.
open Int	`getRepeatedWallTimeOption()` [icu]Gets the behavior for handling wall time repeating multiple times at negative time zone offset transitions.
open Int	`getSkippedWallTimeOption()` [icu]Gets the behavior for handling skipped wall time at positive time zone offset transitions.
Date!	`getTime()` Returns this Calendar's current time.
open Long	`getTimeInMillis()` Returns this Calendar's current time as a long.
open TimeZone!	`getTimeZone()` Returns the time zone.
open String!	`getType()` [icu] Returns the calendar type name string for this Calendar object.
open Calendar.WeekData!	`getWeekData()` [icu] Return simple, immutable struct-like class for access to the week data in this calendar.
open static Calendar.WeekData!	`getWeekDataForRegion(region: String!)` [icu] Return simple, immutable struct-like class for access to the CLDR week data.
open Int	`hashCode()` Returns a hash code for this calendar.
open Boolean	`isEquivalentTo(other: Calendar!)` [icu] Returns true if the given Calendar object is equivalent to this one.
open Boolean	`isLenient()` Tell whether date/time interpretation is to be lenient.
Boolean	`isSet(field: Int)` Determines if the given time field has a value set.
open Boolean	`isWeekend(date: Date!)` [icu] Returns true if the given date and time is in the weekend in this calendar system.
open Boolean	`isWeekend()` [icu] Returns true if this Calendar's current date and time is in the weekend in this calendar system.
Unit	`roll(field: Int, up: Boolean)` Rolls (up/down) a single unit of time on the given field.
open Unit	`roll(field: Int, amount: Int)` Rolls (up/down) a specified amount time on the given field.
Unit	`set(field: Int, value: Int)` Sets the time field with the given value.
Unit	`set(year: Int, month: Int, date: Int)` Sets the values for the fields year, month, and date.
Unit	`set(year: Int, month: Int, date: Int, hour: Int, minute: Int)` Sets the values for the fields year, month, date, hour, and minute.
Unit	`set(year: Int, month: Int, date: Int, hour: Int, minute: Int, second: Int)` Sets the values for the fields year, month, date, hour, minute, and second.
open Unit	`setFirstDayOfWeek(value: Int)` Sets what the first day of the week is, where 1 = `SUNDAY` and 7 = `SATURDAY`.
open Unit	`setLenient(lenient: Boolean)` Specify whether or not date/time interpretation is to be lenient.
open Unit	`setMinimalDaysInFirstWeek(value: Int)` Sets what the minimal days required in the first week of the year are.
open Unit	`setRepeatedWallTimeOption(option: Int)` [icu]Sets the behavior for handling wall time repeating multiple times at negative time zone offset transitions.
open Unit	`setSkippedWallTimeOption(option: Int)` [icu]Sets the behavior for handling skipped wall time at positive time zone offset transitions.
Unit	`setTime(date: Date!)` Sets this Calendar's current time with the given Date.
open Unit	`setTimeInMillis(millis: Long)` Sets this Calendar's current time from the given long value.
open Unit	`setTimeZone(value: TimeZone!)` Sets the time zone with the given time zone value.
open Calendar!	`setWeekData(wdata: Calendar.WeekData!)` [icu] Set data in this calendar based on the WeekData input.
open String	`toString()` Returns a string representation of this calendar.

Protected methods
open Unit	`complete()` Fills in any unset fields in the time field list.
open Unit	`computeFields()` Converts the current millisecond time value `time` to field values in `fields[]`.
Unit	`computeGregorianFields(julianDay: Int)` Compute the Gregorian calendar year, month, and day of month from the Julian day.
open Int	`computeGregorianMonthStart(year: Int, month: Int)` Compute the Julian day of a month of the Gregorian calendar.
open Int	`computeJulianDay()` Compute the Julian day number as specified by this calendar's fields.
open Int	`computeMillisInDay()` Compute the milliseconds in the day from the fields.
open Unit	`computeTime()` Converts the current field values in `fields[]` to the millisecond time value `time`.
open Int	`computeZoneOffset(millis: Long, millisInDay: Int)` This method can assume EXTENDED_YEAR has been set.
open String!	`fieldName(field: Int)` Returns a string name for a field, for debugging and exceptions.
static Long	`floorDivide(numerator: Long, denominator: Long)` Divide two long integers, returning the floor of the quotient.
static Int	`floorDivide(numerator: Int, denominator: Int)` Divide two integers, returning the floor of the quotient.
static Int	`floorDivide(numerator: Int, denominator: Int, remainder: IntArray!)` Divide two integers, returning the floor of the quotient, and the modulus remainder.
static Int	`floorDivide(numerator: Long, denominator: Int, remainder: IntArray!)` Divide two integers, returning the floor of the quotient, and the modulus remainder.
open Array<Array<IntArray!>!>!	`getFieldResolutionTable()` Returns the field resolution array for this calendar.
Int	`getGregorianDayOfMonth()` Returns the day of month (1-based) on the Gregorian calendar as computed by `computeGregorianFields()`.
Int	`getGregorianDayOfYear()` Returns the day of year (1-based) on the Gregorian calendar as computed by `computeGregorianFields()`.
Int	`getGregorianMonth()` Returns the month (0-based) on the Gregorian calendar as computed by `computeGregorianFields()`.
Int	`getGregorianYear()` Returns the extended year on the Gregorian calendar as computed by `computeGregorianFields()`.
open Int	`getLimit(field: Int, limitType: Int)` Returns a limit for a field.
Int	`getStamp(field: Int)` Returns the timestamp of a field.
static Int	`gregorianMonthLength(y: Int, m: Int)` Returns the length of a month of the Gregorian calendar.
static Int	`gregorianPreviousMonthLength(y: Int, m: Int)` Returns the length of a previous month of the Gregorian calendar.
open Unit	`handleComputeFields(julianDay: Int)` Subclasses may override this method to compute several fields specific to each calendar system.
open Int	`handleComputeJulianDay(bestField: Int)` Subclasses may override this.
abstract Int	`handleComputeMonthStart(eyear: Int, month: Int, useMonth: Boolean)` Returns the Julian day number of day before the first day of the given month in the given extended year.
open IntArray!	`handleCreateFields()` Subclasses that use additional fields beyond those defined in `Calendar` should override this method to return an `int[]` array of the appropriate length.
open DateFormat!	`handleGetDateFormat(pattern: String!, locale: Locale!)` Creates a `DateFormat` appropriate to this calendar.
open DateFormat!	`handleGetDateFormat(pattern: String!, override: String!, locale: Locale!)` Creates a `DateFormat` appropriate to this calendar.
open DateFormat!	`handleGetDateFormat(pattern: String!, locale: ULocale!)` Creates a `DateFormat` appropriate to this calendar.
abstract Int	`handleGetExtendedYear()` Returns the extended year defined by the current fields.
abstract Int	`handleGetLimit(field: Int, limitType: Int)` Subclass API for defining limits of different types.
open Int	`handleGetMonthLength(extendedYear: Int, month: Int)` Returns the number of days in the given month of the given extended year of this calendar system.
open Int	`handleGetYearLength(eyear: Int)` Returns the number of days in the given extended year of this calendar system.
Int	`internalGet(field: Int)` Returns the value for a given time field.
Int	`internalGet(field: Int, defaultValue: Int)` Returns the value for a given time field, or return the given default value if the field is not set.
Long	`internalGetTimeInMillis()` Returns the current milliseconds without recomputing.
Unit	`internalSet(field: Int, value: Int)` Set a field to a value.
static Boolean	`isGregorianLeapYear(year: Int)` Determines if the given year is a leap year.
static Int	`julianDayToDayOfWeek(julian: Int)` Returns the day of week, from SUNDAY to SATURDAY, given a Julian day.
static Long	`julianDayToMillis(julian: Int)` Converts Julian day to time as milliseconds.
static Int	`millisToJulianDay(millis: Long)` Converts time as milliseconds to Julian day.
open Int	`newerField(defaultField: Int, alternateField: Int)` Returns the field that is newer, either defaultField, or alternateField.
open Int	`newestStamp(first: Int, last: Int, bestStampSoFar: Int)` Returns the newest stamp of a given range of fields.
open Unit	`pinField(field: Int)` Adjust the specified field so that it is within the allowable range for the date to which this calendar is set.
open Unit	`prepareGetActual(field: Int, isMinimum: Boolean)` Prepare this calendar for computing the actual minimum or maximum.
open Int	`resolveFields(precedenceTable: Array<Array<IntArray!>!>!)` Given a precedence table, return the newest field combination in the table, or -1 if none is found.
open Unit	`validateField(field: Int)` Validate a single field of this calendar.
Unit	`validateField(field: Int, min: Int, max: Int)` Validate a single field of this calendar given its minimum and maximum allowed value.
open Unit	`validateFields()` Ensure that each field is within its valid range by calling `validateField(int)` on each field that has been set.
open Int	`weekNumber(desiredDay: Int, dayOfPeriod: Int, dayOfWeek: Int)` Returns the week number of a day, within a period.
Int	`weekNumber(dayOfPeriod: Int, dayOfWeek: Int)` Returns the week number of a day, within a period.

Properties
static Date!	`MAX_DATE` The maximum supported `Date`.
static Date!	`MIN_DATE` The minimum supported `Date`.

Parameters
`zone`	TimeZone!: the time zone to use
`aLocale`	Locale!: the locale for the week data

Parameters
`zone`	TimeZone!: the time zone to use
`locale`	ULocale!: the ulocale for the week data

Parameters
`field`	Int: the time field.
`amount`	Int: the amount to add to the field.

Parameters
`o`	the object to be compared.
`that`	the `Calendar` to compare to this.

Exceptions
`java.lang.NullPointerException`	if that `Calendar` is null.
`java.lang.ClassCastException`	if the specified object's type prevents it from being compared to this object.
`java.lang.IllegalArgumentException`	if the time of that `Calendar` can't be obtained because of invalid calendar values.

Parameters
`when`	Date!: the date to compare this calendar's time to
`field`	Int: the field in which to compute the result

Parameters
`key`	String!: one of the keys supported by this service. For now, only "calendar" is supported.
`locale`	ULocale!: the locale
`commonlyUsed`	Boolean: if set to true it will return only commonly used values with the given locale in preferred order. Otherwise, it will return all the available values for the locale.

Parameters
`field`	Int: the calendar field to roll.
`up`	Boolean: indicates if the value of the specified time field is to be rolled up or rolled down. Use `true` if rolling up, `false` otherwise.

Parameters
`field`	Int: the given time field.
`value`	Int: the value to be set for the given time field.

Parameters
`year`	Int: the value used to set the YEAR time field.
`month`	Int: the value used to set the MONTH time field. Month value is 0-based. e.g., 0 for January.
`date`	Int: the value used to set the DATE time field.

Parameters
`year`	Int: extended Gregorian year
`month`	Int: zero-based Gregorian month

Parameters
`millis`	Long: milliseconds of the date fields (local midnight millis)
`millisInDay`	Int: milliseconds of the time fields; may be out or range.

Parameters
`numerator`	Long: the numerator
`denominator`	Long: a divisor which must be > 0

Parameters
`numerator`	Int: the numerator
`denominator`	Int: a divisor which must be > 0

Parameters
`field`	Int: the field, from 0..`getFieldCount()-1`
`limitType`	Int: the type specifier for the limit

Parameters
`eyear`	Int: the extended year
`month`	Int: the zero-based month, or 0 if useMonth is false
`useMonth`	Boolean: if false, compute the day before the first day of the given year, otherwise, compute the day before the first day of the given month

Parameters
`pattern`	String!: the pattern, specific to the `DateFormat` subclass
`locale`	Locale!: the locale for which the symbols should be drawn

Parameters
`pattern`	String!: the pattern, specific to the `DateFormat` subclass
`override`	String!: The override string. A numbering system override string can take one of the following forms: 1). If just a numbering system name is specified, it applies to all numeric fields in the date format pattern. 2). To specify an alternate numbering system on a field by field basis, use the field letters from the pattern followed by an = sign, followed by the numbering system name. For example, to specify that just the year be formatted using Hebrew digits, use the override "y=hebr". Multiple overrides can be specified in a single string by separating them with a semi-colon. For example, the override string "m=thai;y=deva" would format using Thai digits for the month and Devanagari digits for the year.
`locale`	Locale!: the locale for which the symbols should be drawn

Parameters
`field`	Int: one of the above field numbers
`limitType`	Int: one of `MINIMUM`, `GREATEST_MINIMUM`, `LEAST_MAXIMUM`, or `MAXIMUM`

Parameters
`field`	Int: the given time field.
`defaultValue`	Int: value to return if field is not set

Calendar

Summary

Constants

AM

AM_PM

APRIL

AUGUST

DATE

DAY_OF_MONTH

DAY_OF_WEEK

DAY_OF_WEEK_IN_MONTH

DAY_OF_YEAR

DECEMBER

DOW_LOCAL

DST_OFFSET

EPOCH_JULIAN_DAY

ERA

EXTENDED_YEAR

FEBRUARY

FRIDAY

GREATEST_MINIMUM

HOUR

HOUR_OF_DAY

INTERNALLY_SET

IS_LEAP_MONTH

JANUARY

JAN_1_1_JULIAN_DAY

JULIAN_DAY

JULY

JUNE

LEAST_MAXIMUM

MARCH

MAXIMUM

MAX_FIELD_COUNT

MAX_JULIAN

MAX_MILLIS

MAY

MILLISECOND

MILLISECONDS_IN_DAY

MINIMUM

MINIMUM_USER_STAMP

MINUTE

MIN_JULIAN

MIN_MILLIS

MONDAY

MONTH

NOVEMBER

OCTOBER

ONE_DAY

ONE_HOUR

ONE_MINUTE

ONE_SECOND

ONE_WEEK

PM

RESOLVE_REMAP

SATURDAY

SECOND

SEPTEMBER

SUNDAY

THURSDAY

TUESDAY

UNDECIMBER

UNSET

WALLTIME_FIRST

WALLTIME_LAST

WALLTIME_NEXT_VALID

WEDNESDAY

WEEK_OF_MONTH

WEEK_OF_YEAR

YEAR

YEAR_WOY

ZONE_OFFSET

Protected constructors

Calendar

Calendar

Calendar

Public methods

add

after

before

Parameters
`desiredDay`	Int: The `DAY_OF_YEAR` or `DAY_OF_MONTH` whose week number is desired. Should be 1 for the first day of the period.
`dayOfPeriod`	Int: The `DAY_OF_YEAR` or `DAY_OF_MONTH` for a day in the period whose `DAY_OF_WEEK` is specified by the `dayOfWeek` parameter. Should be 1 for first day of period.
`dayOfWeek`	Int: The `DAY_OF_WEEK` for the day corresponding to the `dayOfPeriod` parameter. 1-based with 1=Sunday.