EthiopicCalendar

Add a signed amount to a specified field, using this calendar's rules. For example, to add three days to the current date, you can call add(Calendar.DATE, 3).

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

Adding a positive value always means moving forward in time, so for the Gregorian calendar, starting with 100 BC and adding +1 to year results in 99 BC (even though this actually reduces the numeric value of the field itself).

[icu] Note: The ICU implementation of this method is able to add to all fields except for ERA, DST_OFFSET, and 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 getActualMinimum and 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 override 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 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.

Compares the time field records. Equivalent to comparing result of conversion to UTC.

Compares the time field records. Equivalent to comparing result of conversion to UTC.

Clears the values of all the time fields.

Clears the value in the given time field.

Overrides Cloneable

Compares the times (in millis) represented by two Calendar objects.

Fills in any unset fields in the time field list.

Converts the current millisecond time value time to field values in fields[]. This synchronizes 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.

Compute the Gregorian calendar year, month, and day of month from the Julian day. These values are not stored in fields, but in member variables gregorianXxx. They are used for time zone computations and by subclasses that are Gregorian derivatives. Subclasses may call this method to perform a Gregorian calendar millis->fields computation. To perform a Gregorian calendar fields->millis computation, call computeGregorianMonthStart().

Compute the Julian day of a month of the Gregorian calendar. Subclasses may call this method to perform a Gregorian calendar fields->millis computation. To perform a Gregorian calendar millis->fields computation, call computeGregorianFields().

Compute the Julian day number as specified by this calendar's fields.

Compute the milliseconds in the day from the fields. This is a value from 0 to 23:59:59.999 inclusive, unless fields are out of range, in which case it can be an arbitrary value. This value reflects local zone wall time.

Converts the current field values in fields[] to the millisecond time value time.

This method can assume EXTENDED_YEAR has been set.

Compares this calendar to the specified object. The result is true if and only if the argument is not null and is a Calendar object that represents the same calendar as this object.

[icu] Returns the difference between the given time and the time this calendar object is set to. If this calendar is set before the given time, the returned value will be positive. If this calendar is set after the given time, the returned value will be negative. The field parameter specifies the units of the return value. For example, if fieldDifference(when, Calendar.MONTH) returns 3, then this calendar is set to 3 months before , and possibly some additional time less than one month.

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);

Returns a string name for a field, for debugging and exceptions.

Divide two integers, returning 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.

Divide two integers, returning the floor of the quotient, and the modulus remainder.

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.

Divide two integers, returning the floor of the quotient, and the modulus remainder.

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.

Divide two long integers, returning 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.

Returns the value for a given time field.

Returns the maximum value that this field could have, given the current date. For example, with the Gregorian date February 3, 1997 and the DAY_OF_MONTH field, the actual maximum is 28; for February 3, 1996 it is 29.

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

Returns the minimum value that this field could have, given the current date. For most fields, this is the same as getMinimum and getGreatestMinimum. However, some fields, especially those related to week number, are more complicated.

For example, assume getMinimalDaysInFirstWeek returns 4 and 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.

Returns the list of locales for which Calendars are installed.

[icu] Returns a DateFormat appropriate to this calendar. Subclasses wishing to specialize this behavior should override #handleGetDateFormat.

[icu] Returns a DateFormat appropriate to this calendar. Subclasses wishing to specialize this behavior should override #handleGetDateFormat.

Returns the name of this calendar in the language of the given locale.

Returns the name of this calendar in the language of the given locale.

[icu] Returns the number of fields defined by this calendar. Valid field arguments to set() and get() are 0..getFieldCount()-1.

Returns the field resolution array for this calendar. Calendars that define additional fields or change the semantics of existing fields should override this method to adjust the field resolution semantics accordingly. Other subclasses should not override this method.

Returns what the first day of the week is, where 1 = SUNDAY and 7 = SATURDAY. e.g., Sunday in US, Monday in France

Returns the highest minimum value for the given field if varies. Otherwise same as getMinimum(). For Gregorian, no difference.

Returns the day of month (1-based) on the Gregorian calendar as computed by computeGregorianFields().

Returns the day of year (1-based) on the Gregorian calendar as computed by computeGregorianFields().

Returns the month (0-based) on the Gregorian calendar as computed by computeGregorianFields().

Returns the extended year on the Gregorian calendar as computed by computeGregorianFields().

Returns a calendar using the default time zone and locale.

Returns a calendar using the specified time zone and default locale.

Returns a calendar with the specified time zone and locale.

Returns a calendar with the specified time zone and locale.

Returns a calendar using the default time zone and specified locale.

Returns a calendar using the default time zone and specified locale.

[icu] Given a key and a locale, returns an array of string values in a preferred order that would make a difference. These are all and only those values where the open (creation) of the service with the locale formed from the input locale plus input keyword and that value has different behavior than creation with the input locale alone.

Returns the lowest maximum value for the given field if varies. Otherwise same as getMaximum(). e.g., for Gregorian DAY_OF_MONTH, 28.

Returns a limit for a field.

Returns the maximum value for the given time field. e.g. for Gregorian DAY_OF_MONTH, 31.

Returns what the minimal days required in the first week of the year are. That is, if the first week is defined as one that contains the first day of the first month of a year, getMinimalDaysInFirstWeek returns 1. If the minimal days required must be a full week, getMinimalDaysInFirstWeek returns 7.

Returns the minimum value for the given time field. e.g., for Gregorian DAY_OF_MONTH, 1.

[icu]Gets the behavior for handling wall time repeating multiple times at negative time zone offset transitions.

[icu]Gets the behavior for handling skipped wall time at positive time zone offset transitions.

Returns the timestamp of a field.

Returns this Calendar's current time.

Returns this Calendar's current time as a long.

Returns the time zone.

[icu] Return simple, immutable struct-like class for access to the week data in this calendar.

[icu] Return simple, immutable struct-like class for access to the CLDR week data.

Returns the length of a month of the Gregorian calendar.

Returns the length of a previous month of the Gregorian calendar.

Subclasses may override this. This method calls handleGetMonthLength() to obtain the calendar-specific month length.

Subclasses that use additional fields beyond those defined in Calendar should override this method to return an int[] array of the appropriate length. The length must be at least BASE_FIELD_COUNT and no more than MAX_FIELD_COUNT.

Creates a DateFormat appropriate to this calendar. This is a framework method for subclasses to override. This method is responsible for creating the calendar-specific DateFormat and DateFormatSymbols objects as needed.

Creates a DateFormat appropriate to this calendar. This is a framework method for subclasses to override. This method is responsible for creating the calendar-specific DateFormat and DateFormatSymbols objects as needed.

Creates a DateFormat appropriate to this calendar. This is a framework method for subclasses to override. This method is responsible for creating the calendar-specific DateFormat and DateFormatSymbols objects as needed.

Returns the number of days in the given month of the given extended year of this calendar system. Subclasses should override this method if they can provide a more correct or more efficient implementation than the default implementation in Calendar.

Returns the number of days in the given extended year of this calendar system. Subclasses should override this method if they can provide a more correct or more efficient implementation than the default implementation in Calendar.

Returns a hash code for this calendar.

Returns the value for a given time field. This is an internal method for subclasses that does not trigger any calculations.

Returns the value for a given time field, or return the given default value if the field is not set. This is an internal method for subclasses that does not trigger any calculations.

Returns the current milliseconds without recomputing.

Set a field to a value. Subclasses should use this method when computing fields. It sets the time stamp in the stamp[] array to INTERNALLY_SET. If a field that may not be set by subclasses is passed in, an IllegalArgumentException is thrown. This prevents subclasses from modifying fields that are intended to be calendar-system invariant.

[icu] Returns true if the given Calendar object is equivalent to this one. An equivalent Calendar will behave exactly as this one does, but it may be set to a different time. By contrast, for the equals() method to return true, the other Calendar must be set to the same time.

Determines if the given year is a leap year. Returns true if the given year is a leap year.

Tell whether date/time interpretation is to be lenient.

Determines if the given time field has a value set.

[icu] Returns true if this Calendar's current date and time is in the weekend in this calendar system.

[icu] Returns true if the given date and time is in the weekend in this calendar system. Equivalent to calling setTime() followed by isWeekend(). Note: This method changes the time this calendar is set to.

Returns the day of week, from SUNDAY to SATURDAY, given a Julian day.

Converts Julian day to time as milliseconds.

Converts time as milliseconds to Julian day.

Returns the field that is newer, either defaultField, or alternateField. If neither is newer or neither is set, return defaultField.

Returns the newest stamp of a given range of fields.

Adjust the specified field so that it is within the allowable range for the date to which this calendar is set. For example, in a Gregorian calendar pinning the DAY_OF_MONTH field for a calendar set to April 31 would cause it to be set to April 30.

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

Note: pinField is implemented in terms of getActualMinimum and 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.

Prepare this calendar for computing the actual minimum or maximum. This method modifies this calendar's fields; it is called on a temporary calendar.

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.

Given a precedence table, return the newest field combination in the table, or -1 if none is found.

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.

Rolls (up/down) a single unit of time on the given field. If the field is rolled past its maximum allowable value, it will "wrap" back to its minimum and continue rolling. For example, to roll the current date up by one day, you can call:

roll(DATE, true)

When rolling on the YEAR field, it will roll the year value in the range between 1 and the value returned by calling getMaximum(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.

Rolling up always means rolling forward in time (unless the limit of the field is reached, in which case it may pin or wrap), so for the Gregorian calendar, starting with 100 BC and rolling the year up results in 99 BC. When eras have a definite beginning and end (as in the Chinese calendar, or as in most eras in the Japanese calendar) then rolling the year past either limit of the era will cause the year to wrap around. When eras only have a limit at one end, then attempting to roll the year past that limit will result in pinning the year at that limit. Note that for most calendars in which era 0 years move forward in time (such as Buddhist, Hebrew, or Islamic), it is possible for add or roll to result in negative years for era 0 (that is the only way to represent years before the calendar epoch in such calendars).

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.

Rolls (up/down) a specified amount time on the given field. For example, to roll the current date up by three days, you can call roll(Calendar.DATE, 3). If the field is rolled past its maximum allowable value, it will "wrap" back to its minimum and continue rolling. For example, calling roll(Calendar.DATE, 10) on a Gregorian calendar set to 4/25/96 will result in the date 4/5/96.

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 by +1, the DAY_OF_MONTH field must be adjusted so that the result is 2/29/96 rather than the invalid 2/31/96.

Rolling by a positive value always means rolling forward in time (unless the limit of the field is reached, in which case it may pin or wrap), so for the Gregorian calendar, starting with 100 BC and rolling the year by + 1 results in 99 BC. When eras have a definite beginning and end (as in the Chinese calendar, or as in most eras in the Japanese calendar) then rolling the year past either limit of the era will cause the year to wrap around. When eras only have a limit at one end, then attempting to roll the year past that limit will result in pinning the year at that limit. Note that for most calendars in which era 0 years move forward in time (such as Buddhist, Hebrew, or Islamic), it is possible for add or roll to result in negative years for era 0 (that is the only way to represent years before the calendar epoch in such calendars).

[icu] Note: the ICU implementation of this method is able to roll all fields except for ERA, DST_OFFSET, and 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 getActualMinimum and getActualMaximum. For most such fields, simple addition, subtraction, and modulus operations are sufficient to perform the roll. For week-related fields, the results of getFirstDayOfWeek and 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 override 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 android.icu.util.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.

Sets the time field with the given value.

Sets the values for the fields year, month, and date. Previous values of other fields are retained. If this is not desired, call clear() first.

Sets the values for the fields year, month, date, hour, and minute. Previous values of other fields are retained. If this is not desired, call clear() first.

Sets the values for the fields year, month, date, hour, minute, and second. Previous values of other fields are retained. If this is not desired, call #clear first.

Sets what the first day of the week is, where 1 = SUNDAY and 7 = SATURDAY.

Specify whether or not date/time interpretation is to be lenient. With lenient interpretation, a date such as "February 942, 1996" will be treated as being equivalent to the 941st day after February 1, 1996. With strict interpretation, such dates will cause an exception to be thrown.

Sets what the minimal days required in the first week of the year are. For example, if the first week is defined as one that contains the first day of the first month of a year, call the method with value 1. If it must be a full week, use value 7.

[icu]Sets the behavior for handling wall time repeating multiple times at negative time zone offset transitions. For example, 1:30 AM on November 6, 2011 in US Eastern time (America/New_York) occurs twice; 1:30 AM EDT, then 1:30 AM EST one hour later. When WALLTIME_FIRST is used, the wall time 1:30AM in this example will be interpreted as 1:30 AM EDT (first occurrence). When WALLTIME_LAST is used, it will be interpreted as 1:30 AM EST (last occurrence). The default value is WALLTIME_LAST.

[icu]Sets the behavior for handling skipped wall time at positive time zone offset transitions. For example, 2:30 AM on March 13, 2011 in US Eastern time (America/New_York) does not exist because the wall time jump from 1:59 AM EST to 3:00 AM EDT. When WALLTIME_FIRST is used, 2:30 AM is interpreted as 30 minutes before 3:00 AM EDT, therefore, it will be resolved as 1:30 AM EST. When WALLTIME_LAST is used, 2:30 AM is interpreted as 31 minutes after 1:59 AM EST, therefore, it will be resolved as 3:30 AM EDT. When WALLTIME_NEXT_VALID is used, 2:30 AM will be resolved as next valid wall time, that is 3:00 AM EDT. The default value is WALLTIME_LAST.

Note:This option is effective only when this calendar is lenient. When the calendar is strict, such non-existing wall time will cause an exception.

Sets this Calendar's current time with the given Date.

Note: Calling setTime with Date(Long.MAX_VALUE) or Date(Long.MIN_VALUE) may yield incorrect field values from get(int).

Sets this Calendar's current time from the given long value. An IllegalIcuArgumentException is thrown when millis is outside the range permitted by a Calendar object when in strict mode. When in lenient mode the out of range values are pinned to their respective min/max.

Sets the time zone with the given time zone value.

[icu] Set data in this calendar based on the WeekData input.

Returns a string representation of this calendar. This method is intended to be used only for debugging purposes, and the format of the returned string may vary between implementations. The returned string may be empty but may not be null.

Validate a single field of this calendar. Subclasses should override this method to validate any calendar-specific fields. Generic fields can be handled by Calendar.validateField().

Validate a single field of this calendar given its minimum and maximum allowed value. If the field is out of range, throw a descriptive IllegalArgumentException. Subclasses may use this method in their implementation of validateField(int).

Ensure that each field is within its valid range by calling validateField(int) on each field that has been set. This method should only be called if this calendar is not lenient.

Returns the week number of a day, within a period. This may be the week number in a year, or the week number in a month. Usually this will be a value >= 1, but if some initial days of the period are excluded from week 1, because getMinimalDaysInFirstWeek is > 1, then the week number will be zero for those initial days. This method requires the day of week for the given date in order to determine the result.

Subclassing:
This method is intended for use by subclasses in implementing their computeTime and/or computeFields methods. It is often useful in getActualMinimum and getActualMaximum as well.

Returns the week number of a day, within a period. This may be the week number in a year or the week number in a month. Usually this will be a value >= 1, but if some initial days of the period are excluded from week 1, because getMinimalDaysInFirstWeek is > 1, then the week number will be zero for those initial days. This method requires the day number and day of week for some known date in the period in order to determine the day of week on the desired day.

Subclassing:
This method is intended for use by subclasses in implementing their computeTime and/or computeFields methods. It is often useful in getActualMinimum and getActualMaximum as well.

This variant is handy for computing the week number of some other day of a period (often the first or last day of the period) when its day of the week is not known but the day number and day of week for some other day in the period (e.g. the current date) is known.