Calendar Klasse

Definition

[Android.Runtime.Register("android/icu/util/Calendar", ApiSince=24, DoNotGenerateAcw=true)]
public abstract class Calendar : Java.Lang.Object, IDisposable, Java.IO.ISerializable, Java.Lang.ICloneable, Java.Lang.IComparable

[<Android.Runtime.Register("android/icu/util/Calendar", ApiSince=24, DoNotGenerateAcw=true)>]
type Calendar = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ICloneable
    interface IComparable

Vererbung

Object

JavaObject

Object

Calendar

Abgeleitet

Android.Icu.Util.CECalendar

Android.Icu.Util.ChineseCalendar

Android.Icu.Util.GregorianCalendar

Android.Icu.Util.HebrewCalendar

Android.Icu.Util.IndianCalendar

Mehr…

Attribute

RegisterAttribute

Implementiert

IJavaObject IJavaPeerable ISerializable ICloneable IComparable IDisposable

Hinweise

<strong>[icu enhancement]</strong> ICU Ersetzung für java.util.Calendar.  Methoden, Felder und andere für ICU spezifische Funktionen werden als "<strong>[icu]</strong>" bezeichnet.

Calendar ist eine abstrakte Basisklasse zum Konvertieren zwischen einem Date Objekt und einer Reihe ganzzahliger Felder wie YEAR, , MONTH, DAY, HOURusw. (Ein Date Objekt stellt eine bestimmte Zeit mit Millisekundengenauigkeit dar. Informationen zur Date Klasse finden Sie Date unter.)

Unterklassen von Calendar Interpretationen Date gemäß den Regeln eines bestimmten Kalendersystems. ICU4J enthält mehrere Unterklassen, die verschiedene internationale Kalendersysteme implementieren.

Wie bei anderen gebietsschemasensitiven Klassen Calendar wird eine Klassenmethode getInstancezum Abrufen eines allgemein nützlichen Objekts dieses Typs bereitgestellt. CalendarDie Methode gibt einen Kalender eines Typs getInstance zurück, der für das Gebietsschema geeignet ist, dessen Zeitfelder mit dem aktuellen Datum und der aktuellen Uhrzeit initialisiert wurden: <Blockquote>

Calendar rightNow = Calendar.getInstance()

</blockquote>

Wenn ein Tag ULocale und wert verwendet getInstancewerden, werden das Tagcalendar und der Wert abgerufen, wenn vorhanden. Wenn ein erkannter Wert angegeben wird, wird ein Kalender bereitgestellt und entsprechend konfiguriert. Derzeit erkannte Tags sind "buddhistisch", "chinesisch", "coptic", "ethiopisch", "gregorianisch", "hebräisch", "islamisch", "islamisch", "japanisch" und "roc". Beispiel: <Blockquote>

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

</blockquote> gibt eine Instanz von JapaneseCalendar zurück (mit en_US Konventionen für Mindesttage in der ersten Woche, Starttag der Woche, et cetera).

Ein Calendar Objekt kann alle Zeitfeldwerte erzeugen, die zum Implementieren der Datum-Uhrzeit-Formatierung für eine bestimmte Sprache und eine bestimmte Kalenderformatvorlage (z. B. Japanisch-Gregorianisch, Japanese-Traditional) erforderlich sind. Calendar definiert den Von bestimmten Feldern zurückgegebenen Wertebereich sowie deren Bedeutung. Beispielsweise hat der erste Monat des Jahres einen Wert MONTH == JANUARY für alle Kalender. Andere Werte werden von der konkreten Unterklasse definiert, z ERA . B. und YEAR. Ausführliche Informationen finden Sie in der Dokumentation zu einzelnen Felden und Unterklassen.

Wenn ein Calendar Wert lenient</em> ist<>, akzeptiert er einen breiteren Bereich von Feldwerten, als er erzeugt. Zum Beispiel interpretiertGregorianCalendarMONTH == ein lenient JANUARY , DAY_OF_MONTH == 32 als 1. Februar. Ein nicht lenient GregorianCalendar löst eine Ausnahme aus, wenn außerhalb des Bereichs Einstellungen angegeben werden. Wenn Kalender Feldwerte für die Rückgabe neu get()kompensieren, normalisieren sie sie. Beispielsweise erzeugt GregorianCalendar ein DAY_OF_MONTH Immer Werte zwischen 1 und der Länge des Monats.

Calendar definiert eine gebietsschemaspezifische siebentägige Woche mit zwei Parametern: den ersten Tag der Woche und die minimalen Tage in der ersten Woche (von 1 bis 7). Diese Zahlen werden aus den Gebietsschemaressourcendaten entnommen, wenn ein Calendar Gebietsschema erstellt wird. Sie können auch explizit über die API angegeben werden.

Beim Festlegen oder Abrufen der WEEK_OF_MONTHWEEK_OF_YEAR Felder Calendar muss die erste Woche des Monats oder Jahres als Referenzpunkt bestimmt werden. Die erste Woche eines Monats oder Jahres wird als frühester siebenTägiger Zeitraum definiert, der an getFirstDayOfWeek() mindestens getMinimalDaysInFirstWeek() Tagen dieses Monats oder Jahres beginnt und enthält. Wochen nummeriert ..., -1, 0 vor der ersten Woche; Wochen nummeriert 2, 3,... folgen Sie ihr. Beachten Sie, dass die normalisierte Nummerierung, die von get() ihnen zurückgegeben wird, möglicherweise unterschiedlich ist. Beispielsweise kann eine bestimmte Calendar Unterklasse die Woche vor Woche 1 eines Jahres als Woche <em>n</em> des Vorjahrs festlegen.

Bei der Berechnung von Date Zeitfeldern können einige besondere Umstände auftreten: Es gibt möglicherweise nicht genügend Informationen, um die Date Daten zu berechnen (z. B. nur Jahr und Monat, aber keinen Tag im Monat), es können inkonsistente Informationen (z. B. "Dienstag, 15. Juli 1996" - 15. Juli 1996 tatsächlich ein Montag) oder die Eingabezeit aufgrund des Zeitzonenübergangs nicht eindeutig sein.

<starke>unzureichende Informationen.</strong> Der Kalender verwendet Standardinformationen, um die fehlenden Felder anzugeben. Dies kann je nach Kalender variieren; für den gregorianischen Kalender entspricht der Standardwert für ein Feld dem des Beginns der Epoche: d. h. JAHR = 1970, MONAT = JANUAR, DATUM = 1 usw.

<starke>inkonsistente Informationen.</strong> If fields conflict, the calendar will give preference to fields set more recently. Wenn Sie beispielsweise den Tag bestimmen, sucht der Kalender nach einer der folgenden Kombinationen von Feldern. Die letzte Kombination, die durch das zuletzt festgelegte einzelne Feld bestimmt wird, wird verwendet.

<Blockquote>

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

</blockquote>

Für die Tageszeit:

<Blockquote>

HOUR_OF_DAY
            AM_PM + HOUR

</blockquote>

<starke>mehrdeutige Wanduhrzeit.</strong> Wenn sich der Zeitoffset von UTC geändert hat, erzeugt es ein mehrdeutiges Zeitfenster um den Übergang. So beobachten beispielsweise viele US-Standorte Sommerzeit. Am Datum wechselt die Sommerzeit in den USA, Wanduhrzeit springt von 12:59 Uhr (Standard) bis 2:00 Uhr (Tageslicht). Daher ist die Wanduhrzeit von 1:00 bis 1:59 Uhr nicht am Datum vorhanden. Wenn die Eingabewandzeit in dieses fehlende Zeitfenster fällt, löst der ICU-Kalender die Zeit mithilfe des UTC-Offsets vor dem Übergang standardmäßig auf. In diesem Beispiel wird 1:30 Uhr als Standardzeit von 1:30 Uhr interpretiert (nicht vorhanden), sodass das Endergebnis 2:30 Uhr Sommerzeit ist.

Am Datumswechsel zur Standardzeit wird die Wanduhrzeit um 2:00 Uhr um eine Stunde zurück verschoben. So die Wanduhrzeit von 1:00 uhr bis 1:59 Uhr zweimal. In diesem Fall löst der ICU-Kalender die Zeit mit dem UTC-Offset nach dem Übergang standardmäßig auf. Beispielsweise wird 1:30 Uhr am Datum als Standardzeit von 1:30 Uhr aufgelöst.

Mehrdeutige Auflösungsverhalten der Wanduhr kann durch Kalender-APIs #setRepeatedWallTimeOption(int) und #setSkippedWallTimeOption(int). Diese Methoden sind in ICU 49 oder höheren Versionen verfügbar.

<strong>Note:</strong> for some non-Gregorian calendars, different fields may be necessary for complete disambiguation. Eine vollständige Spezifikation des historialen arabischen astronomischen Kalenders erfordert z. B. Jahr, Monat, Tag-von-Monat <em>und</em> Wochentag in einigen Fällen.

<strong>Hinweis:</strong> Es gibt bestimmte Mögliche Mehrdeutigkeiten bei der Interpretation bestimmter Singularzeiten, die auf folgende Weise gelöst werden: <ol><li> 24:00:00 "gehört" zum folgenden Tag. Das heißt, 23:59 am 31. Dezember 1969 < 24:00 Am 1. Januar 1970 < 24:01:00 Am 1. Januar 1970

li Obwohl historisch nicht genau, Mitternacht gehört auch zu "am", und Mittag gehört zu "pm", so am selben Tag, 12:00 Uhr (Mitternacht) < 12:01 Uhr und 12:00 Uhr (Mittag) < 12:01 Pm /ol

Die Datums- oder Uhrzeitformatzeichenfolgen sind nicht Teil der Definition eines Kalenders, da diese vom Benutzer zur Laufzeit geändert oder außer Kraft gesetzt werden müssen. Wird zum Formatieren von Datumsangaben verwendet DateFormat .

<Starke>Feldmanipulationsmethoden</stark>

Calendar Felder können mit drei Methoden geändert werden: set(), , add()und roll().

<Strong>set(f, value)</strong> changes field f to value. Darüber hinaus wird eine interne Membervariable so festgelegt, dass das Feld f geändert wurde. Obwohl das Feld f sofort geändert wird, wird die Millisekunden des Kalenders erst neu komputiert, wenn der nächste Aufruf von get(), getTime()oder getTimeInMillis() es erfolgt. Daher lösen mehrere Aufrufe set() nicht mehrere, unnötige Berechnungen aus. Durch das Ändern eines Felds mithilfe set()von anderen Feldern können sich auch abhängig vom Feld, dem Feldwert und dem Kalendersystem ändern. Darüber hinaus wird nicht unbedingt zurückgegebenget(f), value nachdem die Felder neu komputiert wurden. Die Besonderheiten werden durch die konkrete Kalenderklasse bestimmt.

<em>Example</em>: Consider a GregorianCalendar originally set to August 31, 1999. Anruf set(Calendar.MONTH, Calendar.SEPTEMBER) legt den Kalender auf den 31. September 1999 fest. Dies ist eine temporäre interne Darstellung, die auf den 1. Oktober 1999 aufgelöst wird, wenn getTime()dann aufgerufen wird. Ein Aufruf vor set(Calendar.DAY_OF_MONTH, 30) dem Aufruf zum getTime() Festlegen des Kalenders auf den 30. September 1999, da nach set() sich selbst keine Neukompilierung erfolgt.

<strong>add(f, delta)</strong> add to delta field f. Dies entspricht dem Aufrufen set(f, get(f) + delta) mit zwei Anpassungen:

<Blockquote>

<starke>Regel 1</stark> hinzufügen. Der Wert des Felds f nach dem Aufruf minus dem Wert des Felds f vor dem Aufruf , deltamodulo any overflow that has occurred in field f. Überlauf tritt auf, wenn ein Feldwert seinen Bereich überschreitet und folglich das nächste größere Feld inkrementiert oder erhöht wird und der Feldwert wieder in seinen Bereich angepasst wird.

<strong>Add rule 2</strong>. Wenn ein kleineres Feld invariant sein wird, aber   es ist unmöglich, dass es aufgrund von Änderungen an seinem Minimalwert oder Maximum gleich sein kann, nachdem das Feld f geändert wurde, dann wird sein Wert so nah wie möglich an seinen erwarteten Wert angepasst. Ein kleineres Feld stellt eine kleinere Zeiteinheit dar. HOUR ist ein kleineres Feld als DAY_OF_MONTH. Es wird keine Anpassung an kleineren Feldern vorgenommen, die nicht unveränderlich sein sollen. Das Kalendersystem bestimmt, welche Felder invariant sein sollen.

</blockquote>

Im Gegensatz dazu erzwingt die set()add() sofortige Neukompilierung der Millisekunden des Kalenders und aller Felder.

<em>Example</em>: Consider a GregorianCalendar originally set to August 31, 1999. Durch Anrufe add(Calendar.MONTH, 13) wird der Kalender auf den 30. September 2000 festgelegt. <starke>Add-Regel 1</strong> legt das MONTH Feld auf September fest, da das Hinzufügen von 13 Monaten bis August September des nächsten Jahres. Da DAY_OF_MONTH in einem GregorianCalendarstarken <>Add-Regel 2</strong> nicht 31 im September sein kann, wird der DAY_OF_MONTH Wert auf 30 festgelegt, der nächstmögliche Wert. Obwohl es sich um ein kleineres Feld handelt, DAY_OF_WEEK wird nicht durch Regel 2 angepasst, da es erwartet wird, dass sich der Monat in einem GregorianCalendarändert.

<"strong>roll(f, delta)</strong>" wird dem Feld delta hinzugefügtf, ohne größere Felder zu ändern. Dies entspricht dem Aufrufen add(f, delta) mit der folgenden Anpassung:

<Blockquote>

<starke>Rollregel</stark>. Größere Felder bleiben nach dem Aufruf unverändert. Ein größeres Feld stellt eine größere Zeiteinheit dar. DAY_OF_MONTH ist ein größeres Feld als HOUR.

</blockquote>

<em>Example</em>: Consider a GregorianCalendar originally set to August 31, 1999. Anruf roll(Calendar.MONTH, 8) legt den Kalender auf den 30. April fest, <stark>1999</strong>. Regel 1 hinzufügen legt das MONTH Feld auf April fest. Bei Verwendung eines GregorianCalendar, der DAY_OF_MONTH nicht 31 im Monat April sein kann. Fügen Sie Regel 2 hinzu, um sie auf den nächstmöglichen Wert 30 zu setzen. Schließlich behält die <starke>Rollregel</Starke> den YEAR Feldwert von 1999 bei.

<em>Example</em>: Consider a GregorianCalendar originally set to Sunday June 6, 1999. Anruf roll(Calendar.WEEK_OF_MONTH, -1) legt den Kalender auf Dienstag, den 1. Juni 1999 fest, während der Anruf add(Calendar.WEEK_OF_MONTH, -1) den Kalender auf Sonntag, den 30. Mai 1999 festlegt. Dies liegt daran, dass durch die Rollregel eine zusätzliche Einschränkung auferlegt wird: Die MONTH Änderung darf nicht geändert werden, wenn das WEEK_OF_MONTH Rollup ausgeführt wird. Zusammen mit dem Addieren von Regel 1 muss das resultierende Datum zwischen dienstags 1. Juni und Samstag, 5. Juni, sein. Nach dem Hinzufügen von Regel 2 wird die DAY_OF_WEEK, eine invariante, beim Ändern des WEEK_OF_MONTH, auf Dienstag festgelegt, der am nächsten mögliche Wert zu Sonntag (wobei Sonntag der erste Tag der Woche ist).

<starkes>Nutzungsmodell</stark>. Um das Verhalten von add() und roll()zu motivieren, ziehen Sie eine Benutzeroberflächenkomponente mit Inkrement- und Dekrementschaltflächen für den Monat, Tag und Jahr und eine zugrunde liegende GregorianCalendarKomponente in Betracht. Wenn die Benutzeroberfläche den 31. Januar 1999 liest und der Benutzer die Schaltfläche "Monatinkrementierung" drückt, was sollte sie lesen? Wenn die zugrunde liegende Implementierung verwendet set()wird, kann sie den 3. März 1999 lesen. Ein besseres Ergebnis wäre der 28. Februar 1999. Darüber hinaus sollte der Benutzer, wenn der Benutzer erneut die Schaltfläche "Monatinkrementierung" drückt, den 31. März 1999 und nicht den 28. März 1999 lesen. Wenn Sie das ursprüngliche Datum speichern und entweder add() oder roll()verwenden, je nachdem, ob größere Felder betroffen sein sollen, kann sich die Benutzeroberfläche so verhalten, wie die meisten Benutzer intuitiv erwarten.

<b>Hinweis:</b> Sie sollten immer verwenden #roll roll und #add add nicht versuchen, arithmetische Vorgänge direkt auf den Feldern einer .Calendar Es ist durchaus möglich, dass Calendar Unterklassen Felder mit nicht linearen Verhaltensweisen aufweisen, z. B. fehlende Monate oder Tage während Nicht-Schaltjahren. Die Unterklassen add und roll Methoden berücksichtigen dies, während einfache arithmetische Manipulationen ungültige Ergebnisse liefern können.

<big><big><b>Kalenderarchitektur in ICU4J</b></big/big><>

Kürzlich hat sich die Implementierung Calendar erheblich geändert, um die Unterklassen besser zu unterstützen. Die ursprüngliche Calendar Klasse wurde entwickelt, um Unterklassen zu unterstützen, aber es verfügte nur über eine implementierte Unterklasse. GregorianCalendar Mit der Implementierung mehrerer neuer Kalenderunterklassen, einschließlich der BuddhistCalendarChineseCalendar, , HebrewCalendar, IslamicCalendarund , und JapaneseCalendar, wurde die Unterklassen-API gründlich überarbeitet. In diesem Abschnitt werden die neue Unterklassen-API und andere Arten erläutert, in denen android.icu.util.Calendar sich die Unterschiede unterscheiden java.util.Calendar.

<big><b>Änderungen</b></groß>

Übersicht über Änderungen zwischen der klassischen Calendar Architektur und der neuen Architektur.

<Ul>

<li>Das fields[] Array ist private jetzt anstelle von protected. Unterklassen müssen mit den Methoden #internalSet und #internalGet. <b>Motivation:</b> Unterklassen sollten nicht direkt auf Datenmitglieder zugreifen.</li>

<li>Das time lange Wort ist private jetzt anstelle von protected. Unterklassen können mithilfe der Methode #internalGetTimeInMillisdarauf zugreifen, was keine Aktualisierung provoziert. <b>Motivation:</b> Unterklassen sollten nicht direkt auf Datenmitglieder zugreifen.</li>

<li>Der Zuständigkeitsbereich der Unterklassen wurde drastisch reduziert. So viele Funktionen wie möglich werden in der Calendar Basisklasse implementiert. Daher ist es viel einfacher, Unterklassen zu untergliedern Calendar. <b>Motivation:</b-Unterklassen> sollten keinen gemeinsamen Code erneut anwenden müssen. Bestimmte Verhaltensweisen gelten für kalenderübergreifende Systeme: Die Definition und das Verhalten von wochenbezogenen Feldern und Zeitfeldern, das arithmetische (#add(int, int) add und #roll(int, int) roll) Verhalten vieler Felder und das Feldüberprüfungssystem.</li>

<li>Die Unterklassen-API wurde vollständig neu gestaltet.</li>

<li>Die Calendar Basisklasse enthält einige gregorianische Kalenderalgorithmusunterstützung, die Unterklassen verwenden können (insbesondere in #handleComputeFields). Unterklassen können die Methoden getGregorianXxx() verwenden, um vorkompilierte Werte abzurufen. <b>Motivation:</b> Dies ist für alle Calendar Unterklassen erforderlich, um ein konsistentes Zeitzonenverhalten zu implementieren, und gregorianische abgeleitete Systeme können die bereits berechneten Daten verwenden.</li>

<li>Die FIELD_COUNT Konstante wurde entfernt. Verwenden Sie #getFieldCount. Darüber hinaus wurde die Framework-API hinzugefügt, damit Unterklassen zusätzliche Felder definieren können. <b>Motivation: </b>Die Anzahl der Felder ist nicht konstant über Kalendersysteme hinweg.</li>

<li>Der Bereich der gehandhabten Datumsangaben wurde von +/- ~300.000.000 Jahre auf +/- ~5.000.000 Jahre verengt. In der Praxis sollte sich dies nicht auf Kunden auswirken. Dies bedeutet jedoch, dass Clientcode keine garantierten ergebnisse mit Datumsangaben wie Date(Long.MIN_VALUE) z. B. oder Date(Long.MAX_VALUE). Stattdessen sollten die Calendar geschützten Konstanten verwendet werden. <b>Motivation:</b> Mit dem Hinzufügen des #JULIAN_DAY Felds müssen julianische Tagesnummern auf eine 32-Bit-Version intbeschränkt werden. Dadurch wird der gesamte unterstützte Bereich eingeschränkt. Darüber hinaus vereinfacht das Einschränken des unterstützten Bereichs die Berechnung durch Entfernen von Sonderfallcode, der verwendet wurde, um arithmetischen Überlauf bei Millimetern in der Nähe und in der Nähe Long.MIN_VALUE zu Long.MAX_VALUEberücksichtigen.</li>

<li>Neue Felder werden implementiert: #JULIAN_DAY definiert die Einzelfeldspezifikation des Datums. #MILLISECONDS_IN_DAY definiert eine Ein-Feld-Spezifikation der Wandzeit. #DOW_LOCAL und #YEAR_WOY implementieren Sie lokalisiertes Wochen- und Wochen- und Wochenverhalten.</li>

<li-Unterklassen>können auf geschützte Millisekundenkonstanten zugreifen, die in Calendardefiniert sind.</li>

<li>New API wurde hinzugefügt, um kalenderspezifische Unterklassen von DateFormat.</li>

<li>Mehrere Unterklassen wurden implementiert, die verschiedene internationale Kalendersysteme darstellen.</li>

</ul>

<big><b>Subclass API</b></big>

Die ursprüngliche Calendar API basiert auf der Erfahrung der Implementierung einer einzigen Unterklasse. GregorianCalendar Daher waren nicht alle Unterklassenknicken herausgearbeitet worden. Die neue Unterklassen-API wurde basierend auf mehreren implementierten Unterklassen optimiert. Dazu gehören Methoden, die überschrieben werden müssen, und Methoden, damit Unterklassen aufgerufen werden können. Unterklassen haben keinen direkten Zugriff mehr auf fields und stamp. Stattdessen verfügen sie über eine neue API für den Zugriff auf diese. Unterklassen können das fields Array über eine geschützte Frameworkmethode zuordnen. Dadurch können Unterklassen zusätzliche Felder angeben.

Weitere Funktionen wurden in die Basisklasse verschoben. Die Basisklasse enthält nun einen Großteil der Computermaschinen zur Unterstützung des gregorianischen Kalenders. Dies basiert auf zwei Dingen: (1) Viele Kalender basieren auf dem gregorianischen Kalender (z. B. dem buddhistischen und japanischen Kaiserkalender). (2) <em>All</em-Kalender> erfordern grundlegende gregorianische Unterstützung, um Zeitzonenberechnungen zu verarbeiten.

Allgemeine Berechnungen wurden verschoben.Calendar Unterklassen berechnen die wochenbezogenen Felder und die zeitbezogenen Felder nicht mehr. Diese werden in der Regel für alle Kalender von der Basisklasse behandelt.

<b>Unterklassenberechnung von Zeitfeldern=></b>

Die #ERAFelder , #YEAR, #EXTENDED_YEAR, #MONTH, #DAY_OF_MONTHund #DAY_OF_YEAR Felder werden von der Unterklasse berechnet, basierend auf dem julianischen Tag. Alle anderen Felder werden berechnet von Calendar.

<Ul>

<Li-Unterklassen>sollten implementiert werden#handleComputeFields, um die #ERAFelder #YEAR#EXTENDED_YEAR#MONTH#DAY_OF_MONTH#DAY_OF_YEAR , die auf dem Wert des #JULIAN_DAY Felds basieren. Wenn kalenderspezifische Felder nicht definiert Calendarsind, müssen sie ebenfalls berechnet werden. Dies sind die einzigen Felder, die von der Unterklasse berechnet werden sollen. Alle anderen Felder werden von der Basisklasse berechnet, sodass sich Zeit- und Wochenfelder in allen Kalendern einheitlich verhalten. Die Standardversion dieser Methode in Calendar implementiert einen proleptischen gregorianischen Kalender. Innerhalb dieser Methode können Unterklassen aufgerufen getGregorianXxx() werden, um den gregorianischen Kalendermonat, den Tag des Monats und das erweiterte Jahr für das angegebene Datum abzurufen.</li>

</ul>

<b>Unterklassenberechnung von Feldern => Zeit</b>

Die Interpretation der meisten Feldwerte wird vollständig von Calendar. Calendar bestimmt, welche Felder festgelegt sind, welche nicht, welche in letzter Zeit festgelegt werden usw. Behandelt außerdem Calendar die Berechnung der Uhrzeit aus den Zeitfeldern und behandelt die wochenbezogenen Felder. Das einzige, was die Unterklasse tun muss, ist das verlängerte Jahr, basierend auf den Feldern des Jahres, und dann, wenn ein verlängertes Jahr und ein Monat, eine julianische Tageszahl zurückgeben muss.

<Ul>

<li-Unterklassen>sollten implementiert werden #handleGetExtendedYear , um das verlängerte Jahr für dieses Kalendersystem basierend auf dem #YEAR, #EXTENDED_YEARund allen Feldern, die das Kalendersystem verwendet, die größer als ein Jahr sind, wie z #ERA. B. .</li>

<Li-Unterklassen>sollten implementiert werden #handleComputeMonthStart , um die julianische Tageszahl zurückzugeben, die einem Monat und einem verlängerten Jahr zugeordnet ist. Dies ist die Julianische Tageszahl des Tages vor dem ersten Tag des Monats. Die Monatszahl ist nullbasiert. Diese Berechnung sollte nicht von Feldwerten abhängen.</li>

</ul>

<b>Andere Methoden</b>

<Ul>

<Li-Unterklassen>sollten implementiert werden #handleGetMonthLength , um die Anzahl der Tage in einem bestimmten Monat eines bestimmten verlängerten Jahres zurückzugeben. Die Monatszahl ist wie immer nullbasiert.</li>

<Li-Unterklassen>sollten implementiert werden #handleGetYearLength , um die Anzahl der Tage im angegebenen verlängerten Jahr zurückzugeben. Diese Methode wird verwendet computeWeekFields , um die #WEEK_OF_YEAR Felder #YEAR_WOY zu berechnen.</li>

<li-Unterklassen>sollten implementiert werden #handleGetLimit , um die geschützten Werte eines Felds abhängig vom Wert eines limitTypeFelds zurückzugeben. Diese Methode muss nur die Felder #ERA, , #YEAR, #MONTH, #WEEK_OF_YEAR, #WEEK_OF_MONTH, #DAY_OF_MONTH, #DAY_OF_YEAR, , , #DAY_OF_WEEK_IN_MONTH, und #YEAR_WOY.#EXTENDED_YEAR Andere Felder sind invariant (im Hinblick auf das Kalendersystem) und werden von der Basisklasse behandelt.</li>

< >Li Optional können Unterklassen außer Kraft setzen#validateField, um unterklassenspezifische Felder zu überprüfen. Wenn der Wert des Felds außerhalb des Zulässigen liegt, sollte die Methode eine IllegalArgumentException. Die Methode kann zum Behandeln von Feldern auf generische Weise aufgerufen super.validateField(field) werden, d. h., sie mit dem Bereich getMinimum(field)zu vergleichen.getMaximum(field)</li>

< >li Optional können Unterklassen außer Kraft setzen#handleCreateFields, um ein int[] Array zu erstellen, das groß genug ist, um die Felder des Kalenders zu enthalten. Dies ist nur erforderlich, wenn der Kalender zusätzliche Felder definiert, die von diesen definiert Calendarwerden. Die Länge des Ergebnisses muss zwischen der Basis und der maximalen Feldanzahl sein.</li>

< >li Optional können Unterklassen außer Kraft setzen#handleGetDateFormat, um einen DateFormat geeigneten Kalender zu erstellen. Dies ist nur erforderlich, wenn eine Kalenderunterklasse die Verwendung eines Felds neu definiert (z. B. das Feld von einem symbolischen Feld in ein numerisches Feld ändert #ERA ) oder ein zusätzliches Feld definiert.</li>

<Li>Optional können Unterklassen Felder außer Kraft setzen #roll roll und #add add verarbeiten, die nicht zusammenhängend sind. Beispielsweise im hebräischen Kalender den Monat " Adar I" tritt nur in Schaltjahren auf; in anderen Jahren springt der Kalender von Shevat (Monat #4) zu Adar (Monat #6). Die HebrewCalendar#add HebrewCalendar.add Methoden HebrewCalendar#roll HebrewCalendar.roll berücksichtigen dies, sodass das Hinzufügen von 1 Monat zu Shevat das richtige Ergebnis (Adar) in einem Nicht-Schaltjahr gibt. Die geschützte Hilfsmethode #pinField pinField ist bei der Implementierung dieser beiden Methoden häufig hilfreich. </li>

</ul>

<big><b>Normalisiertes Verhalten</b></big>

Das Verhalten bestimmter Felder wurde in allen Kalendersystemen konsistent gemacht und in Calendar.

<Ul>

<li>Zeit ist normalisiert. Obwohl einige Kalendersysteme zwischen Tagen bei Sonnenuntergang oder zu anderen Zeiten wechseln, wechseln alle ICU4J-Kalender zwischen Tagen in <der>lokalen Zone Mitternacht</em>. Dadurch kann ICU4J die Zeitberechnungen Calendar zentralisieren und grundlegende Korrespondenzen zwischen Kalendersystemen verwalten. Betroffene Felder: #AM_PM, , #HOUR, #HOUR_OF_DAY#MINUTE, #SECOND, , #MILLISECOND, und #ZONE_OFFSET#DST_OFFSET.</li>

<li>DST-Verhalten wird normalisiert. Das Verhalten der Sommerzeit wird für alle Kalendersysteme gleich berechnet und hängt vom Wert mehrerer GregorianCalendar Felder ab: das #YEAR, #MONTHund #DAY_OF_MONTH. Calendar Daher werden diese Felder immer berechnet, auch für nicht gregorianische Kalendersysteme. Diese Felder sind für Unterklassen verfügbar.</li>

<li>Wochen werden normalisiert. Obwohl Gebietsschemas die Woche anders definieren, verwenden sie in Bezug auf den Tag, an dem sie beginnt, und die Bezeichnung der Woche nummer eins eines Monats oder Jahres, sie alle verwenden einen gemeinsamen Mechanismus. Darüber hinaus hat der Wochentag eine einfache und konsistente Definition während der gesamten Geschichte. Obwohl der gregorianische Kalender beim ersten Institut eine Einstellung eingeführt hat, wurde der Wochentag nicht gestört. Aus diesem Grund werden die Felder #DAY_OF_WEEK, WEEK_OF_YEAR, WEEK_OF_MONTH, #DAY_OF_WEEK_IN_MONTH, #DOW_LOCAL, #YEAR_WOY alle auf einheitliche Weise in der Basisklasse berechnet, basierend auf dem #EXTENDED_YEAR, #DAY_OF_YEAR, #MONTH, und #DAY_OF_MONTH, die von der Unterklasse berechnet werden.</li>

</ul>

<big><b>Unterstützte Reichweite</b></big>

Der zulässige Bereich Calendar wurde eingegrenzt. GregorianCalendar wird verwendet, um zu versuchen, den Bereich von Datumsangaben mit Millisekundenwerten von Long.MIN_VALUE bis zu Long.MAX_VALUEunterstützen. Dadurch wurden ungünstige Konstruktionen (Hacks) eingeführt, die die Leistung verlangsamten. Außerdem wurde ein nicht einheitliches Verhalten an den Grenzen eingeführt. Das neue Calendar Protokoll gibt den maximalen Bereich der unterstützten Datumsangaben an, die julianische Tageszahlen enthalten-0x7F000000+0x7F000000. Dies entspricht Jahren von ~5.800.000 BCE bis ~5.800.000 CE. Programmierer sollten die geschützten Konstanten verwenden, um ein extrem frühes Calendar oder extrem spätes Datum anzugeben.

<big><b>Allgemeine Notizen</b></groß>

<Ul>

<li>Calendars-Implementierungen sind <em>proleptic</em>. Auch wenn der gregorianische Kalender erst im 16. Jahrhundert eingeleitet wurde, unterstützt die GregorianCalendar Klasse Datumsangaben vor beginn des Kalenders, indem das Kalendersystem rückwärts erweitert wird. Ebenso erstreckt sich der HebrewCalendar Rückschritt vor dem Beginn seiner Epoche in null und negative Jahre. Unterklassen lösen keine Ausnahmen aus, da ein Datum vor dem historischen Start eines Kalendersystems steht. Stattdessen implementieren #handleGetLimit sie, um geeignete Grenzwerte für #YEARFelder, #ERAusw. zurückzugeben. Wenn der Kalender dann nicht lenient ist, löst Out-of-Range-Feldwerte eine Ausnahme aus.</li>

<Li>Calendar system subclasses compute a <em>extended year</em>. Dies unterscheidet sich von dem #YEAR Feld, in dem es sich über alle ganzzahligen Werte erstreckt, einschließlich Null- und negativer Werte, und es kapselt die Informationen des #YEAR Felds und aller größeren Felder. Für den gregorianischen Kalender wird die #EXTENDED_YEAR Berechnung also wie ERA==AD ? YEAR : 1-YEARfolgt berechnet. Ein weiteres Beispiel ist die mayan lange Anzahl, die Jahre (KUN) und geschachtelte Zyklen von Jahren (KATUN und BAKTUN). Der Mayan #EXTENDED_YEAR wird als TUN + 20 * (KATUN + 20 * BAKTUN). Die Calendar Basisklasse verwendet das #EXTENDED_YEAR Feld, um die wochenbezogenen Felder zu berechnen.</li>

</ul>

Java Dokumentation für android.icu.util.Calendar.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.