Java Doc for Calendar.java in  » Internationalization-Localization » icu4j » com » ibm » icu » util » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Note: This class is similar, but not identical, to the class java.util.Calendar. Changes are detailed below.

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", and "japanese". For example:

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

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.

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

1. 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
2. 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 Calendar.roll roll and Calendar.add 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 com.ibm.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 Calendar.internalSet and Calendar.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 Calendar.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 ( Calendar.add(int,int) add and Calendar.roll(int,int) 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 Calendar.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 Calendar.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 constants Calendar.MIN_DATE , Calendar.MAX_DATE , Calendar.MIN_MILLIS , Calendar.MAX_MILLIS , Calendar.MIN_JULIAN , and Calendar.MAX_JULIAN should be used. Motivation: With the addition of the Calendar.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 accomodate arithmetic overflow at millis near Long.MIN_VALUE and Long.MAX_VALUE.
• New fields are implemented: Calendar.JULIAN_DAY defines single-field specification of the date. Calendar.MILLISECONDS_IN_DAY defines a single-field specification of the wall time. Calendar.DOW_LOCAL and Calendar.YEAR_WOY implement localized day-of-week and week-of-year behavior.
• Subclasses can access millisecond constants Calendar.ONE_SECOND , Calendar.ONE_MINUTE , Calendar.ONE_HOUR , Calendar.ONE_DAY , and Calendar.ONE_WEEK defined in Calendar.
• New API has been added to suport 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 Calendar.ERA , Calendar.YEAR , Calendar.EXTENDED_YEAR , Calendar.MONTH , Calendar.DAY_OF_MONTH , and Calendar.DAY_OF_YEAR fields are computed by the subclass, based on the Julian day. All other fields are computed by Calendar.

• Subclasses should implement Calendar.handleComputeFields to compute the Calendar.ERA , Calendar.YEAR , Calendar.EXTENDED_YEAR , Calendar.MONTH , Calendar.DAY_OF_MONTH , and Calendar.DAY_OF_YEAR fields, based on the value of the Calendar.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 Calendar.handleGetExtendedYear to return the extended year for this calendar system, based on the Calendar.YEAR , Calendar.EXTENDED_YEAR , and any fields that the calendar system uses that are larger than a year, such as Calendar.ERA .
• Subclasses should implement Calendar.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 Calendar.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 Calendar.handleGetYearLength to return the number of days in the given extended year. This method is used by computeWeekFields to compute the Calendar.WEEK_OF_YEAR and Calendar.YEAR_WOY fields.
• Subclasses should implement Calendar.handleGetLimit to return the Calendar.MINIMUM , Calendar.GREATEST_MINIMUM , Calendar.LEAST_MAXIMUM , or Calendar.MAXIMUM of a field, depending on the value of limitType. This method only needs to handle the fields Calendar.ERA , Calendar.YEAR , Calendar.MONTH , Calendar.WEEK_OF_YEAR , Calendar.WEEK_OF_MONTH , Calendar.DAY_OF_MONTH , Calendar.DAY_OF_YEAR , Calendar.DAY_OF_WEEK_IN_MONTH , Calendar.YEAR_WOY , and Calendar.EXTENDED_YEAR . Other fields are invariant (with respect to calendar system) and are handled by the base class.
• Optionally, subclasses may override Calendar.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 Calendar.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 at least Calendar.BASE_FIELD_COUNT and no more than Calendar.MAX_FIELD_COUNT .
• Optionally, subclasses may override Calendar.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 Calendar.ERA field from a symbolic field to a numeric one) or defines an additional field.
• Optionally, subclasses may override Calendar.roll roll and Calendar.add 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 HebrewCalendar.add and HebrewCalendar.roll 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 Calendar.pinField 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 correpsondences between calendar systems. Affected fields: Calendar.AM_PM , Calendar.HOUR , Calendar.HOUR_OF_DAY , Calendar.MINUTE , Calendar.SECOND , Calendar.MILLISECOND , Calendar.ZONE_OFFSET , and Calendar.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 Calendar.YEAR , Calendar.MONTH , and Calendar.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 Calendar.DAY_OF_WEEK , WEEK_OF_YEAR, WEEK_OF_MONTH, Calendar.DAY_OF_WEEK_IN_MONTH , Calendar.DOW_LOCAL , Calendar.YEAR_WOY are all computed in a consistent way in the base class, based on the Calendar.EXTENDED_YEAR , Calendar.DAY_OF_YEAR , Calendar.MONTH , and Calendar.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,000,000 BCE to ~5,000,000 CE. Programmers should use the constants Calendar.MIN_DATE (or Calendar.MIN_MILLIS or Calendar.MIN_JULIAN ) and Calendar.MAX_DATE (or Calendar.MAX_MILLIS or Calendar.MAX_JULIAN ) 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 Calendar.handleGetLimit to return appropriate limits on Calendar.YEAR , Calendar.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 Calendar.YEAR field in that it ranges over all integer values, including zero and negative values, and it encapsulates the information of the Calendar.YEAR field and all larger fields. Thus, for the Gregorian calendar, the Calendar.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 Calendar.EXTENDED_YEAR is computed as TUN + 20 * (KATUN + 20 * BAKTUN). The Calendar base class uses the Calendar.EXTENDED_YEAR field to compute the week-related fields.

When adding to certain fields, the values of other fields may conflict and need to be changed.

Unlike the built-in division, this is mathematically well-behaved. E.g., -1/4 => 0 and -1%4 => -1, but floorDivide(-1,4) => -1 with remainder[0] => 3.
Parameters:
  numerator - the numerator
Parameters:
  denominator - a divisor which must be > 0
Parameters:
  remainder - an array of at least one element in which the valuenumerator mod denominator is returned.

Unlike the built-in division, this is mathematically well-behaved. E.g., -1/4 => 0 and -1%4 => -1, but floorDivide(-1,4) => -1 with remainder[0] => 3.
Parameters:
  numerator - the numerator
Parameters:
  denominator - a divisor which must be > 0
Parameters:
  remainder - an array of at least one element in which the valuenumerator mod denominator is returned.

Subclassing:
This utility method is intended for use by subclasses that need to implement their own overrides of Calendar.roll roll and Calendar.add add .

Note: pinField is implemented in terms of Calendar.getActualMinimum getActualMinimum and Calendar.getActualMaximum getActualMaximum .

Rationale: The semantics of getActualXxx() is to return the maximum or minimum value that the given field can take, taking into account other relevant fields.

The precedence table is a 3-dimensional array of integers.

When adding to certain fields, the values of other fields may conflict and need to be changed. For example, when adding one to the Calendar.MONTH MONTH field for the Gregorian date 1/31/96, the Calendar.DAY_OF_MONTH DAY_OF_MONTH field must be adjusted so that the result is 2/29/96 rather than the invalid 2/31/96.

The com.ibm.icu.util.Calendar implementation of this method is able to add to all fields except for Calendar.ERA ERA , Calendar.DST_OFFSET DST_OFFSET , and Calendar.ZONE_OFFSET ZONE_OFFSET . Subclasses may, of course, add support for additional fields in their overrides of add.

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.

Subclassing:
This implementation of add assumes that the behavior of the field is continuous between its minimum and maximum, which are found by calling Calendar.getActualMinimum getActualMinimum and Calendar.getActualMaximum getActualMaximum . For such fields, simple arithmetic operations are sufficient to perform the add.

Subclasses that have fields for which this assumption of continuity breaks down must overide add to handle those fields specially. 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 HebrewCalendar.add method takes this into account, so that adding one month to a date in Shevat gives the proper result (Adar) in a non-leap year.

Parameters:
  field - the time field.
Parameters:
  amount - the amount to add to the field.
exception:
  IllegalArgumentException - if the field is invalid or refersto a field that cannot be handled by this method.
See Also:   Calendar.roll(int,int)

As a side effect of this call, this calendar is advanced toward when by the given amount. That is, calling this method has the side effect of calling add(field, n), where n is the return value.

Usage: To use this method, call it first with the largest field of interest, then with progressively smaller fields. For example:

 int y = cal.fieldDifference(when, Calendar.YEAR);
 int m = cal.fieldDifference(when, Calendar.MONTH);
 int d = cal.fieldDifference(when, Calendar.DATE);

Note: fieldDifference() is asymmetrical. That is, in the following code:

 cal.setTime(date1);
 int m1 = cal.fieldDifference(date2, Calendar.MONTH);
 int d1 = cal.fieldDifference(date2, Calendar.DATE);
 cal.setTime(date2);
 int m2 = cal.fieldDifference(date1, Calendar.MONTH);
 int d2 = cal.fieldDifference(date1, Calendar.DATE);

Unlike the built-in division, this is mathematically well-behaved. E.g., -1/4 => 0 but floorDivide(-1,4) => -1.
Parameters:
  numerator - the numerator
Parameters:
  denominator - a divisor which must be > 0 the floor of the quotient.

Unlike the built-in division, this is mathematically well-behaved. E.g., -1/4 => 0 but floorDivide(-1,4) => -1.
Parameters:
  numerator - the numerator
Parameters:
  denominator - a divisor which must be > 0 the floor of the quotient.

Unlike the built-in division, this is mathematically well-behaved. E.g., -1/4 => 0 and -1%4 => -1, but floorDivide(-1,4) => -1 with remainder[0] => 3.
Parameters:
  numerator - the numerator
Parameters:
  denominator - a divisor which must be > 0
Parameters:
  remainder - an array of at least one element in which the valuenumerator mod denominator is returned. Unlike numerator% denominator, this will always be non-negative. the floor of the quotient.

Unlike the built-in division, this is mathematically well-behaved. E.g., -1/4 => 0 and -1%4 => -1, but floorDivide(-1,4) => -1 with remainder[0] => 3.
Parameters:
  numerator - the numerator
Parameters:
  denominator - a divisor which must be > 0
Parameters:
  remainder - an array of at least one element in which the valuenumerator mod denominator is returned. Unlike numerator% denominator, this will always be non-negative. the floor of the quotient.

The actual maximum computation ignores smaller fields and the current value of like-sized fields. For example, the actual maximum of the DAY_OF_YEAR or MONTH depends only on the year and supra-year fields. The actual maximum of the DAY_OF_MONTH depends, in addition, on the MONTH field and any other fields at that granularity (such as ChineseCalendar.IS_LEAP_MONTH). The DAY_OF_WEEK_IN_MONTH field does not depend on the current DAY_OF_WEEK; it returns the maximum for any day of week in the current month. Likewise for the WEEK_OF_MONTH and WEEK_OF_YEAR fields.
Parameters:
  field - the field whose maximum is desired the maximum of the given field for the current date of this calendar
See Also:   Calendar.getMaximum
See Also:   Calendar.getLeastMaximum

For example, assume Calendar.getMinimalDaysInFirstWeek getMinimalDaysInFirstWeek returns 4 and Calendar.getFirstDayOfWeek getFirstDayOfWeek returns SUNDAY. If the first day of the month is Sunday, Monday, Tuesday, or Wednesday there will be four or more days in the first week, so it will be week number 1, and getActualMinimum(WEEK_OF_MONTH) will return 1. However, if the first of the month is a Thursday, Friday, or Saturday, there are not four days in that week, so it is week number 0, and getActualMinimum(WEEK_OF_MONTH) will return 0.

Parameters:
  field - the field whose actual minimum value is desired. the minimum of the given field for the current date of this calendar
See Also:   Calendar.getMinimum
See Also:   Calendar.getGreatestMinimum

Note: This method will be implemented in ICU 3.0; ICU 2.8 contains a partial preview implementation. The * actual locale is returned correctly, but the valid locale is not, in most cases.
Parameters:
  type - type of information requested, either com.ibm.icu.util.ULocale.VALID_LOCALE or com.ibm.icu.util.ULocale.ACTUAL_LOCALE. the information specified by type, or null ifthis object was not constructed from locale data.
See Also:   com.ibm.icu.util.ULocale
See Also:   com.ibm.icu.util.ULocale.VALID_LOCALE
See Also:   com.ibm.icu.util.ULocale.ACTUAL_LOCALE

• ERA
• YEAR
• MONTH
• DAY_OF_MONTH
• DAY_OF_YEAR
• EXTENDED_YEAR

In addition, subclasses should compute any subclass-specific fields, that is, fields from BASE_FIELD_COUNT to getFieldCount() - 1.

The default implementation in Calendar implements a pure proleptic Gregorian calendar.

ERA
 YEAR
 MONTH
 WEEK_OF_YEAR
 WEEK_OF_MONTH
 DAY_OF_MONTH
 DAY_OF_YEAR
 DAY_OF_WEEK_IN_MONTH
 YEAR_WOY
 EXTENDED_YEAR

Subclassing:
This utility method is intended for use by subclasses that need to implement their own overrides of Calendar.roll roll and Calendar.add add .

Note: pinField is implemented in terms of Calendar.getActualMinimum getActualMinimum and Calendar.getActualMaximum getActualMaximum . If either of those methods uses a slow, iterative algorithm for a particular field, it would be unwise to attempt to call pinField for that field. If you really do need to do so, you should override this method to do something more efficient for that field.

Parameters:
  field - The calendar field whose value should be pinned.
See Also:   Calendar.getActualMinimum
See Also:   Calendar.getActualMaximum

Rationale: The semantics of getActualXxx() is to return the maximum or minimum value that the given field can take, taking into account other relevant fields. In general these other fields are larger fields. For example, when computing the actual maximum DAY_OF_MONTH, the current value of DAY_OF_MONTH itself is ignored, as is the value of any field smaller.

The time fields all have fixed minima and maxima, so we don't need to worry about them. This also lets us set the MILLISECONDS_IN_DAY to zero to erase any effects the time fields might have when computing date fields.

DAY_OF_WEEK is adjusted specially for the WEEK_OF_MONTH and WEEK_OF_YEAR fields to ensure that they are computed correctly.

The precedence table is a 3-dimensional array of integers. It may be thought of as an array of groups. Each group is an array of lines. Each line is an array of field numbers. Within a line, if all fields are set, then the time stamp of the line is taken to be the stamp of the most recently set field. If any field of a line is unset, then the line fails to match. Within a group, the line with the newest time stamp is selected. The first field of the line is returned to indicate which line matched.

In some cases, it may be desirable to map a line to field that whose stamp is NOT examined. For example, if the best field is DAY_OF_WEEK then the DAY_OF_WEEK_IN_MONTH algorithm may be used. In order to do this, insert the value REMAP_RESOLVE | F at the start of the line, where F is the desired return field value. This field will NOT be examined; it only determines the return value if the other fields in the line are the newest.

If all lines of a group contain at least one unset field, then no line will match, and the group as a whole will fail to match. In that case, the next group will be processed. If all groups fail to match, then -1 is returned.

roll( Calendar.DATE , true)

When rolling on the Calendar.YEAR field, it will roll the year value in the range between 1 and the value returned by calling Calendar.getMaximum getMaximum ( Calendar.YEAR ).

When rolling on certain fields, the values of other fields may conflict and need to be changed. For example, when rolling the MONTH field for the Gregorian date 1/31/96 upward, the DAY_OF_MONTH field must be adjusted so that the result is 2/29/96 rather than the invalid 2/31/96.

Note: Calling roll(field, true) N times is not necessarily equivalent to calling roll(field, N). For example, imagine that you start with the date Gregorian date January 31, 1995. If you call roll(Calendar.MONTH, 2), the result will be March 31, 1995. But if you call roll(Calendar.MONTH, true), the result will be February 28, 1995. Calling it one more time will give March 28, 1995, which is usually not the desired result.

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.

Parameters:
  field - the calendar field to roll.
Parameters:
  up - indicates if the value of the specified time field is to berolled up or rolled down. Use true if rolling up,false otherwise.
exception:
  IllegalArgumentException - if the field is invalid or refersto a field that cannot be handled by this method.
See Also:   Calendar.roll(int,int)
See Also:   Calendar.add

When rolling on certain fields, the values of other fields may conflict and need to be changed. For example, when rolling the Calendar.MONTH MONTH field for the Gregorian date 1/31/96 by +1, the Calendar.DAY_OF_MONTH DAY_OF_MONTH field must be adjusted so that the result is 2/29/96 rather than the invalid 2/31/96.

The com.ibm.icu.util.Calendar implementation of this method is able to roll all fields except for Calendar.ERA ERA , Calendar.DST_OFFSET DST_OFFSET , and Calendar.ZONE_OFFSET ZONE_OFFSET . Subclasses may, of course, add support for additional fields in their overrides of roll.

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.

Subclassing:
This implementation of roll assumes that the behavior of the field is continuous between its minimum and maximum, which are found by calling Calendar.getActualMinimum getActualMinimum and Calendar.getActualMaximum getActualMaximum . For most such fields, simple addition, subtraction, and modulus operations are sufficient to perform the roll. For week-related fields, the results of Calendar.getFirstDayOfWeek getFirstDayOfWeek and Calendar.getMinimalDaysInFirstWeek getMinimalDaysInFirstWeek are also necessary. Subclasses can override these two methods if their values differ from the defaults.

Subclasses that have fields for which the assumption of continuity breaks down must overide roll to handle those fields specially. 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.roll HebrewCalendar.roll method takes this into account, so that rolling the month of Shevat by one gives the proper result (Adar) in a non-leap year.

Parameters:
  field - the calendar field to roll.
Parameters:
  amount - the amount by which the field should be rolled.
exception:
  IllegalArgumentException - if the field is invalid or refersto a field that cannot be handled by this method.
See Also:   Calendar.roll(int,boolean)
See Also:   Calendar.add

Note: Calling setTime() with Date(Long.MAX_VALUE) or Date(Long.MIN_VALUE) may yield incorrect field values from get().
Parameters:
  date - the given Date.