Calendar
is an abstract base class for converting between aUDate
object and a set of integer fields such asYEAR
,MONTH
,DAY
,HOUR
, and so on
Calendar
is an abstract base class for converting between aUDate
object and a set of integer fields such asYEAR
,MONTH
,DAY
,HOUR
, and so on. (AUDate
object represents a specific instant in time with millisecond precision. See {@link UDate} for information about theUDate
class.)Subclasses of
Calendar
interpret aUDate
according to the rules of a specific calendar system. The JDK provides one concrete subclass ofCalendar
:GregorianCalendar
. Future subclasses could represent the various types of lunar calendars in use in many parts of the world.Like other locale-sensitive classes,
Calendar
provides a class method,getInstance
, for getting a generally useful object of this type.Calendar
'sgetInstance
method returns aGregorianCalendar
object whose time fields have been initialized with the current date and time:Calendar rightNow = Calendar.getInstance();A
Calendar
object can produce all the time field values needed to implement the date-time formatting for a particular language and calendar style (for example, Japanese-Gregorian, Japanese-Traditional).When computing a
UDate
from time fields, two special circumstances may arise: there may be insufficient information to compute theUDate
(such as only year and month but no day in the month), or there may be inconsistent information (such as "Tuesday, July 15, 1996" -- July 15, 1996 is actually a Monday).Insufficient information. The calendar will use default information to specify the missing fields. This may vary by calendar; for the Gregorian calendar, the default for a field is the same as that of the start of the epoch: i.e., YEAR = 1970, MONTH = JANUARY, DATE = 1, etc.
Inconsistent information. If fields conflict, the calendar will give preference to fields set more recently. For example, when determining the day, the calendar will look for one of the following combinations of fields. The most recent combination, as determined by the most recently set single field, will be used.
For the time of day:MONTH + DAY_OF_MONTH MONTH + WEEK_OF_MONTH + DAY_OF_WEEK MONTH + DAY_OF_WEEK_IN_MONTH + DAY_OF_WEEK DAY_OF_YEAR DAY_OF_WEEK + WEEK_OF_YEARHOUR_OF_DAY AM_PM + HOURNote: 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 {@link DateFormat} to format dates.
Calendar
provides an API for field "rolling", where fields can be incremented or decremented, but wrap around. For example, rolling the month up in the dateDecember 12, 1996
results inJanuary 12, 1996
.
Calendar
also provides a date arithmetic function for adding the specified (signed) amount of time to a particular time field. For example, subtracting 5 days from the dateSeptember 12, 1996
results inSeptember 7, 1996
.
NOTE: Do not use this method -- use roll(EDateFields, int, UErrorCode&) instead.
The only difference between roll() and add() is that roll() does not change the value of more significant fields when it reaches the minimum or maximum of its range, whereas add() does.
Concrete subclasses of Calendar must implement getDynamicClassID() and also a static method and data member: static UClassID getStaticClassID() { return (UClassID)&fgClassID; } static char fgClassID;
This should really be named areFieldsInSync, but the old name is retained for backward compatibility.
alphabetic index hierarchy of classes
this page has been generated automatically by doc++
(c)opyright by Malte Zöckler, Roland Wunderling
contact: doc++@zib.de