Calendar Classe

Definizione

[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

Ereditarietà

Object

JavaObject

Object

Calendar

Derivato

Android.Icu.Util.CECalendar

Android.Icu.Util.ChineseCalendar

Android.Icu.Util.GregorianCalendar

Android.Icu.Util.HebrewCalendar

Android.Icu.Util.IndianCalendar

Altro…

Attributi

RegisterAttribute

Implementazioni

IJavaObject IJavaPeerable ISerializable ICloneable IComparable IDisposable

Commenti

<strong>[icu enhancement]</strong> ICU's replacement for java.util.Calendar.  Metodi, campi e altre funzionalità specifiche dell'ICU sono etichettati come "<strong>[icu]</strong>".

Calendarè una classe base astratta per la conversione tra un Date oggetto e un set di campi integer, ad YEAResempio , MONTHDAY, , HOURe così via. Un Date oggetto rappresenta un istante specifico nel tempo con precisione in millisecondi. Vedere Date per informazioni sulla Date classe .

Sottoclassi di Calendar interpretare un oggetto Date in base alle regole di un sistema di calendario specifico. ICU4J contiene diverse sottoclassi che implementano sistemi di calendario internazionali diversi.

Analogamente ad altre classi sensibili alle impostazioni locali, Calendar fornisce un metodo di classe, getInstance, per ottenere un oggetto generalmente utile di questo tipo. CalendarIl metodo 's getInstance restituisce un calendario di un tipo appropriato alle impostazioni locali, i cui campi di ora sono stati inizializzati con la data e l'ora correnti: <blockquote>

Calendar rightNow = Calendar.getInstance()

</blockquote>

Quando un ULocale oggetto viene usato da getInstance, il tag e il valore 'calendar' vengono recuperati, se presenti. Se viene specificato un valore riconosciuto, viene fornito e configurato un calendario in base alle esigenze. Attualmente i tag riconosciuti sono "buddista", "cinese", "copto", "ethiopic", "gregoriano", "ebraico", "islamico", "islamic-civil", "giapponese" e "roc". Ad esempio: <blockquote>

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

</blockquote> restituirà un'istanza di JapaneseCalendar (usando le convenzioni di en_US per i giorni minimi della prima settimana, il giorno di inizio della settimana e così via).

Un Calendar oggetto può produrre tutti i valori di campo dell'ora necessari per implementare la formattazione di data e ora per una lingua e uno stile di calendario specifici , ad esempio giapponese gregoriano Japanese-Traditional. Calendar definisce l'intervallo di valori restituiti da determinati campi, nonché il relativo significato. Ad esempio, il primo mese dell'anno ha valore MONTH == JANUARY per tutti i calendari. Altri valori sono definiti dalla sottoclasse concreta, ad esempio ERA e YEAR. Per informazioni dettagliate, vedere la documentazione dei singoli campi e la documentazione della sottoclasse.

Quando un Calendar è <em>lenient</em>, accetta un intervallo più ampio di valori di campo rispetto a quello prodotto. Ad esempio, un leniente GregorianCalendar interpretaMONTH == JANUARY , DAY_OF_MONTH == 32 come 1 febbraio. Un non-leniente GregorianCalendar genera un'eccezione quando vengono specificate impostazioni di campo non compreso nell'intervallo. Quando i calendari ricompilano i valori dei campi per restituiti da get(), li normalizzano. Ad esempio, un GregorianCalendar produce DAY_OF_MONTH sempre valori compresi tra 1 e la lunghezza del mese.

Calendar definisce una settimana di sette giorni specifica delle impostazioni locali usando due parametri: il primo giorno della settimana e i giorni minimi della prima settimana (da 1 a 7). Questi numeri vengono ricavati dai dati delle risorse delle impostazioni locali quando viene costruito un oggetto Calendar . Possono anche essere specificati in modo esplicito tramite l'API.

Quando si impostano o si ottengono i WEEK_OF_MONTH campi o WEEK_OF_YEAR , Calendar è necessario determinare la prima settimana del mese o dell'anno come punto di riferimento. La prima settimana di un mese o di un anno viene definita come il primo periodo di sette giorni che inizia getFirstDayOfWeek() e contiene almeno getMinimalDaysInFirstWeek() giorni del mese o dell'anno. Settimane numerate ..., -1, 0 precedono la prima settimana; settimane numerate 2, 3,... seguirlo. Si noti che la numerazione normalizzata restituita da get() può essere diversa. Ad esempio, una sottoclasse specifica Calendar può designare la settimana prima della settimana 1 di un anno come settimana <em>n</em> dell'anno precedente.

Quando si calcola un Date campo da un'ora, possono verificarsi alcune circostanze speciali: potrebbero verificarsi informazioni insufficienti per calcolare Date (ad esempio solo anno e mese, ma nessun giorno nel mese), potrebbero verificarsi informazioni incoerenti (ad esempio "Martedì, 15 luglio 1996" - 15 luglio 1996 è effettivamente un lunedì) o l'ora di input potrebbe essere ambigua a causa della transizione del fuso orario.

<informazioni insufficienti>.</strong> Il calendario userà le informazioni predefinite per specificare i campi mancanti. Questo può variare in base al calendario; per il calendario gregoriano, il valore predefinito per un campo è uguale a quello dell'inizio dell'epoca, ad esempio YEAR = 1970, MONTH = GENNAIO, DATE = 1 e così via.

<informazioni forti>incoerenti.</strong> Se i campi sono in conflitto, il calendario darà la preferenza ai campi impostati più di recente. Ad esempio, quando si determina il giorno, il calendario cercherà una delle combinazioni di campi seguenti. Verrà usata la combinazione più recente, come determinato dal campo singolo impostato più di recente.

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

Per l'ora del giorno:

<blockquote>

HOUR_OF_DAY
            AM_PM + HOUR

</blockquote>

<forte>tempo di orologio muro ambiguo.</strong> Quando la differenza di ora rispetto all'ora UTC è cambiata, produce una fascia oraria ambigua intorno alla transizione. Ad esempio, molte località degli Stati Uniti osservano l'ora legale. Quando la data passa all'ora legale negli Stati Uniti, l'ora del muro passa dalle 12:59 (standard) alle 2:00 (luce legale). Di conseguenza, l'ora dell'orologio a muro dalle 1:00 alle 1:59 non esiste nella data. Quando l'ora del muro di input rientra in questo intervallo di tempo mancante, il calendario di ICU risolve l'ora usando l'offset UTC prima della transizione per impostazione predefinita. In questo esempio, le 13:30 vengono interpretate come ora solare 1:30 (non esistente), quindi il risultato finale sarà 2:30 ora legale.

Nella data che torna all'ora solare, l'ora del muro viene spostata indietro di un'ora alle 2:00. Quindi, l'ora del muro dalle 1:00 alle 1:59 si verifica due volte. In questo caso, il calendario di ICU risolve l'ora usando l'offset UTC dopo la transizione per impostazione predefinita. Ad esempio, le 13:30 della data vengono risolte come ora solare delle 1:30.

I comportamenti ambigui di risoluzione dell'ora del clock del muro possono essere personalizzati dalle API #setRepeatedWallTimeOption(int) calendario e #setSkippedWallTimeOption(int)da . Questi metodi sono disponibili in ICU 49 o versioni successive.

<nota forte>:</forte> per alcuni calendari non gregoriani, potrebbero essere necessari campi diversi per la disambiguazione completa. Ad esempio, una specifica completa del calendario astronomico arabo istoriale richiede anno, mese, giorno del mese <em>e</em> giorno della settimana in alcuni casi.

<nota forte>:/<forte> Esistono alcune possibili ambiguità nell'interpretazione di determinati tempi singolari, che vengono risolti nei modi seguenti: <ol><li> 24:00:00 "appartiene" al giorno seguente. Cioè, 23:59 il 31 dicembre 1969 < 24:00 il 1° gennaio 1970 < 24:01:00 il 1 gennaio 1970

li Anche se storicamente non preciso, mezzanotte appartiene anche a "am", e mezzogiorno appartiene a "pm", quindi lo stesso giorno, 12:00 (mezzanotte) < 12:01 am e 12:00 pm (mezzogiorno) < 12:01 pm /ol

Le stringhe di formato di data o ora non fanno parte della definizione di un calendario, in quanto devono essere modificabili o sostituibili dall'utente in fase di esecuzione. Usare DateFormat per formattare le date.

<metodi di manipolazione dei campi> sicuri</sicuri>

Calendar i campi possono essere modificati usando tre metodi: set(), add()e roll().

<campo delle modifiche complesse>set(f, value)</complesse> in f.value Imposta inoltre una variabile membro interna per indicare che il campo f è stato modificato. Anche se il campo f viene modificato immediatamente, i millisecondi del calendario non vengono ricalcolate fino a quando non viene eseguita la chiamata successiva a get(), getTime()o getTimeInMillis() . Di conseguenza, più chiamate a set() non attivano più calcoli non necessari. In seguito alla modifica di un campo tramite set(), altri campi possono anche cambiare, a seconda del campo, del valore del campo e del sistema del calendario. Inoltre, get(f) non restituirà value necessariamente dopo la ricompilazione dei campi. Le specifiche sono determinate dalla classe di calendario concreta.

<em>Example</em>: considera un GregorianCalendar valore originariamente impostato sul 31 agosto 1999. La chiamata set(Calendar.MONTH, Calendar.SEPTEMBER) imposta il calendario sul 31 settembre 1999. Si tratta di una rappresentazione interna temporanea che si risolve nel 1° ottobre 1999 se getTime()viene chiamato. Tuttavia, una chiamata a set(Calendar.DAY_OF_MONTH, 30) prima della chiamata a getTime() imposta il calendario sul 30 settembre 1999, poiché non si verifica alcuna ricompilazione dopo set() se stessa.

<strong>add(f, delta)</strong> aggiunge delta al campo f. Equivale a chiamare set(f, get(f) + delta) con due rettifiche:

<blockquote>

<forte>Aggiungi regola 1</forte>. Valore del campo f dopo la chiamata meno il valore di campo f prima della chiamata è delta, modulo qualsiasi overflow che si è verificato nel campo f. L'overflow si verifica quando un valore di campo supera l'intervallo e, di conseguenza, il campo più grande successivo viene incrementato o decrementato e il valore del campo viene regolato nuovamente nell'intervallo.

<forte>Aggiungi regola 2</strong>. Se si prevede che un campo più piccolo sia invariante, ma   è impossibile che sia uguale al valore precedente a causa delle modifiche apportate al valore minimo o massimo dopo la modifica del campo f , quindi il relativo valore viene modificato in modo da essere il più vicino possibile al valore previsto. Un campo più piccolo rappresenta un'unità di tempo inferiore. HOUR è un campo più piccolo di DAY_OF_MONTH. Non viene apportata alcuna modifica ai campi più piccoli che non devono essere invarianti. Il sistema di calendario determina quali campi devono essere invarianti.

</blockquote>

A differenza set()di , inoltre, add() forza una ricompilazione immediata dei millisecondi del calendario e di tutti i campi.

<em>Example</em>: considera un GregorianCalendar valore originariamente impostato sul 31 agosto 1999. La chiamata add(Calendar.MONTH, 13) imposta il calendario sul 30 settembre 2000. <forte>Aggiungi regola 1</forte> imposta il MONTH campo su settembre, poiché l'aggiunta di 13 mesi ad agosto dà settembre del prossimo anno. Poiché DAY_OF_MONTH non può essere 31 nel mese di settembre in un GregorianCalendar, <la regola di aggiunta avanzata>2</strong> imposta su DAY_OF_MONTH 30, il valore più vicino possibile. Anche se si tratta di un campo più piccolo, DAY_OF_WEEK non viene modificato dalla regola 2, poiché si prevede di modificare quando il mese cambia in un oggetto GregorianCalendar.

<strong>roll(f, delta)</strong> aggiunge delta al campo f senza modificare campi più grandi. Equivale a chiamare add(f, delta) con la seguente regolazione:

<blockquote>

<regola>di rollback</avanzata avanzata>. I campi più grandi non vengono modificati dopo la chiamata. Un campo più grande rappresenta un'unità di tempo più grande. DAY_OF_MONTH è un campo più grande di HOUR.

</blockquote>

<em>Example</em>: considera un GregorianCalendar valore originariamente impostato sul 31 agosto 1999. La chiamata roll(Calendar.MONTH, 8) imposta il calendario su 30 aprile, <forte>1999</strong>. Aggiungere la regola 1 imposta il MONTH campo su Aprile. L'utilizzo di , GregorianCalendarnon DAY_OF_MONTH può essere 31 nel mese di aprile. Aggiungere la regola 2 lo imposta sul valore più vicino possibile, 30. Infine, la <>regola< di roll forte/forte> mantiene il YEAR valore del campo del 1999.

<em>Example</em>: considera un GregorianCalendar set originariamente impostato su Domenica 6 giugno 1999. La chiamata roll(Calendar.WEEK_OF_MONTH, -1) imposta il calendario su martedì 1 giugno 1999, mentre la chiamata add(Calendar.WEEK_OF_MONTH, -1) imposta il calendario su domenica 30 maggio 1999. Ciò è dovuto al fatto che la regola di rollio impone un vincolo aggiuntivo: l'oggetto MONTH non deve cambiare quando viene eseguito il WEEK_OF_MONTH rollback. In combinazione con l'aggiunta della regola 1, la data risultante deve essere compresa tra martedì 1 giugno e sabato 5 giugno. In base all'aggiunta della regola 2, , DAY_OF_WEEKun oggetto invariante quando si modifica WEEK_OF_MONTH, è impostato su Martedì, il valore più vicino possibile a Domenica (dove domenica è il primo giorno della settimana).

<strong>Usage model</strong>. Per motivare il comportamento di add() e roll(), considerare un componente dell'interfaccia utente con pulsanti di incremento e decremento per il mese, il giorno e l'anno e un oggetto sottostante GregorianCalendar. Se l'interfaccia legge il 31 gennaio 1999 e l'utente preme il pulsante di incremento del mese, cosa deve leggere? Se l'implementazione sottostante usa set(), potrebbe leggere il 3 marzo 1999. Un risultato migliore sarebbe il 28 febbraio 1999. Inoltre, se l'utente preme di nuovo il pulsante di incremento del mese, dovrebbe leggere il 31 marzo 1999, non il 28 marzo 1999. Salvando la data originale e usando add() o roll(), a seconda che i campi più grandi debbano essere interessati, l'interfaccia utente può comportarsi come la maggior parte degli utenti si aspetterà in modo intuitivo.

<b Nota:>/b<> È consigliabile usare #roll roll sempre e #add add invece di tentare di eseguire operazioni aritmetiche direttamente nei campi di un oggetto Calendar. È possibile che Calendar le sottoclassi abbiano campi con comportamento non lineare, ad esempio mesi o giorni mancanti durante gli anni non bisestili. I metodi e add delle sottoclassi roll prenderanno in considerazione questo problema, mentre le semplici manipolazioni aritmetiche possono dare risultati non validi.

<big><><b>Calendar Architecture in ICU4J</b></big/big></big>

Recentemente l'implementazione di Calendar è cambiata in modo significativo per supportare meglio la sottoclasse. La classe originale Calendar è stata progettata per supportare la sottoclasse, ma aveva solo una sottoclasse implementata, GregorianCalendar. Con l'implementazione di diverse nuove sottoclassi del calendario, tra cui BuddhistCalendar, ChineseCalendarHebrewCalendar, IslamicCalendar, e JapaneseCalendar, l'API di sottoclasse è stata rielaborata accuratamente. Questa sezione descrive in dettaglio la nuova API di sottoclasse e altri modi in cui android.icu.util.Calendar differisce da java.util.Calendar.

<big><b>Changes</b></big>

Panoramica delle modifiche tra l'architettura classica Calendar e la nuova architettura.

<ul>

<li>La fields[] matrice è private ora invece di protected. Le sottoclassi devono accedervi usando i metodi #internalSet e #internalGet. <b>Motivazione:</b> Le sottoclassi non devono accedere direttamente ai membri dei dati.</li>

<li>La time parola lunga è private ora invece di protected. Le sottoclassi possono accedervi usando il metodo #internalGetTimeInMillis, che non provoca un aggiornamento. <b>Motivazione:</b> Le sottoclassi non devono accedere direttamente ai membri dei dati.</li>

<li>L'ambito della responsabilità delle sottoclassi è stato drasticamente ridotto. La maggior parte delle funzionalità possibili viene implementata nella Calendar classe di base. Di conseguenza, è molto più facile sottoclassare Calendar. <b Motivation:/b Subclasses should not have to reimplement common code.b>Motivation:</b> Subclasses should not have to reimplement common code. Alcuni comportamenti sono comuni nei sistemi di calendario: la definizione e il comportamento dei campi relativi alla settimana e ai campi ora, il comportamento aritmetico (#add(int, int) add e #roll(int, int) roll) di molti campi e del sistema di convalida dei campi.</li>

<li>L'API di sottoclasse è stata completamente riprogettata.</li>

<li>La Calendar classe base contiene alcuni supporti algoritmici del calendario gregoriano che le sottoclassi possono usare (in particolare in #handleComputeFields). Le sottoclassi possono usare i metodi getGregorianXxx() per ottenere valori precompilate. <b>Motivazione:</b> Questa operazione è richiesta da tutte le Calendar sottoclassi per implementare un comportamento coerente del fuso orario e i sistemi derivati dal gregoriano possono usare i dati già calcolati.</li>

<li>La FIELD_COUNT costante è stata rimossa. Utilizzare il #getFieldCount. Inoltre, l'API framework è stata aggiunta per consentire alle sottoclassi di definire campi aggiuntivi. <b Motivazione: >/b<>Il numero di campi non è costante nei sistemi di calendario.</li>

<li>L'intervallo di date gestite è stato ristretto da +/- ~300.000.000 anni a +/- ~5.000.000 anni. In termini pratici, questo non deve influire sui client. Tuttavia, significa che il codice client non può essere garantito con risultati ben comportati con date come Date(Long.MIN_VALUE) o Date(Long.MAX_VALUE). È invece consigliabile usare le Calendar costanti protette. <b>Motivazione:</b> Con l'aggiunta del #JULIAN_DAY campo, i numeri di giorno julian devono essere limitati a 32 bit int. In questo modo viene limitato l'intervallo complessivo supportato. Inoltre, la limitazione dell'intervallo supportato semplifica i calcoli rimuovendo il codice case speciale usato per supportare l'overflow aritmetico in prossimità di Long.MIN_VALUEmillis e Long.MAX_VALUE .</li>

< >vengono implementati nuovi campi: #JULIAN_DAY definisce la specifica a campo singolo della data. #MILLISECONDS_IN_DAY definisce una specifica a campo singolo dell'ora del muro. #DOW_LOCAL e #YEAR_WOY implementare il comportamento localizzato giorno della settimana e della settimana dell'anno.</li>

<Le sottoclassi li>possono accedere a costanti millisecondi protette definite in Calendar.</li>

<Li>New API è stata aggiunta per supportare sottoclassi specifiche del calendario di DateFormat.</li>

<sono>state implementate diverse sottoclassi, che rappresentano vari sistemi di calendario internazionali.</li>

</ul>

<BIG><B>Subclass API</b></big>

L'API originale Calendar era basata sull'esperienza di implementazione di una sola sottoclasse, GregorianCalendar. Di conseguenza, tutti i kink di sottoclassazione non erano stati elaborati. La nuova API di sottoclasse è stata perfezionata in base a diverse sottoclassi implementate. Sono inclusi i metodi che devono essere sottoposti a override e metodi per le sottoclassi da chiamare. Le sottoclassi non hanno più accesso diretto a fields e stamp. Hanno invece una nuova API per accedervi. Le sottoclassi sono in grado di allocare la fields matrice tramite un metodo framework protetto. Ciò consente alle sottoclassi di specificare campi aggiuntivi.

Altre funzionalità sono state spostate nella classe di base. La classe base contiene ora gran parte dei macchinari di calcolo per supportare il calendario gregoriano. Questo si basa su due cose: (1) Molti calendari sono basati sul calendario gregoriano (come i calendari imperiali buddisti e giapponesi). (2) <em>Tutti< i calendari em> richiedono il supporto gregoriano di base per gestire i calcoli del fuso orario.

I calcoli comuni sono stati spostati in Calendar. Le sottoclassi non calcolano più i campi correlati alla settimana e i campi correlati all'ora. Questi sono comunemente gestiti per tutti i calendari dalla classe di base.

<b>Calcolo sottoclasse dei campi=> temporali</b>

I #ERAcampi , #YEAR#EXTENDED_YEAR, #MONTH, #DAY_OF_MONTH, e #DAY_OF_YEAR vengono calcolati dalla sottoclasse in base al giorno julian. Tutti gli altri campi vengono calcolati da Calendar.

<ul>

<Le sottoclassi li>devono implementare #handleComputeFields per calcolare i #ERAcampi , #YEAR#EXTENDED_YEAR, #MONTH, #DAY_OF_MONTH, e #DAY_OF_YEAR in base al valore del #JULIAN_DAY campo. Se sono presenti campi specifici del calendario non definiti da Calendar, devono essere calcolati anche. Questi sono gli unici campi che la sottoclasse deve calcolare. Tutti gli altri campi vengono calcolati dalla classe base, quindi i campi di tempo e settimana si comportano in modo coerente in tutti i calendari. La versione predefinita di questo metodo in Calendar implementa un calendario gregoriano proleptico. All'interno di questo metodo, le sottoclassi possono chiamare getGregorianXxx() per ottenere il mese di calendario gregoriano, il giorno del mese e l'anno esteso per la data specificata.</li>

</ul>

<b>Calcolo sottoclasse dei campi => time</b>

L'interpretazione della maggior parte dei valori di campo viene gestita interamente da Calendar. Calendar determina i campi impostati, che non sono, che vengono impostati più di recente e così via. Inoltre, Calendar gestisce il calcolo dell'ora dai campi dell'ora e gestisce i campi correlati alla settimana. L'unica cosa che la sottoclasse deve fare è determinare l'anno esteso, in base ai campi dell'anno, e quindi, dato un anno esteso e un mese, deve restituire un numero di giorno julian.

<ul>

<Le sottoclassi li>devono implementare #handleGetExtendedYear per restituire l'anno esteso per questo sistema di calendario, in base a #YEAR, #EXTENDED_YEARe a tutti i campi utilizzati dal sistema di calendario che sono più grandi di un anno, ad esempio #ERA.</li>

<Le sottoclassi li>devono implementare #handleComputeMonthStart per restituire il numero di giorno julian associato a un mese e all'anno esteso. Questo è il numero di giorno julian del giorno prima del primo giorno del mese. Il numero del mese è in base zero. Questo calcolo non deve dipendere da alcun valore di campo.</li>

</ul>

<b>Altri metodi</b>

<ul>

<Le sottoclassi li>devono implementare #handleGetMonthLength per restituire il numero di giorni in un determinato mese di un determinato anno esteso. Il numero del mese, come sempre, è in base zero.</li>

<Le sottoclassi li>devono implementare #handleGetYearLength per restituire il numero di giorni nell'anno esteso specificato. Questo metodo viene usato da computeWeekFields per calcolare i #WEEK_OF_YEAR campi e #YEAR_WOY .</li>

<Le sottoclassi li>devono implementare #handleGetLimit per restituire i valori protetti di un campo, a seconda del valore di limitType. Questo metodo deve gestire solo i campi #ERA, #YEAR, #MONTH, #WEEK_OF_YEAR, #WEEK_OF_MONTH, #DAY_OF_MONTH#DAY_OF_YEAR#DAY_OF_WEEK_IN_MONTH#YEAR_WOY, e .#EXTENDED_YEAR Altri campi sono invarianti (rispetto al sistema di calendario) e vengono gestiti dalla classe di base.</li>

<li>Facoltativamente, le sottoclassi possono eseguire l'override per controllare i campi specifici della sottoclasse #validateField . Se il valore del campo non è compreso nell'intervallo, il metodo deve generare un'eccezione IllegalArgumentException. Il metodo può chiamare super.validateField(field) per gestire i campi in modo generico, ovvero per confrontarli con l'intervallo getMinimum(field)..getMaximum(field).</li>

<li>Facoltativamente, le sottoclassi possono eseguire l'override #handleCreateFields per creare una int[] matrice sufficientemente grande da contenere i campi del calendario. Questa operazione è necessaria solo se il calendario definisce campi aggiuntivi oltre a quelli definiti da Calendar. La lunghezza del risultato deve essere compresa tra il conteggio dei campi di base e massimo.</li>

<li>Facoltativamente, le sottoclassi possono eseguire l'override #handleGetDateFormat per creare un oggetto DateFormat appropriato per questo calendario. Questa operazione è necessaria solo se una sottoclasse di calendario ridefinisce l'uso di un campo (ad esempio, modifica il #ERA campo da un campo simbolico a un campo numerico) o definisce un campo aggiuntivo.</li>

<li>Facoltativamente, le sottoclassi possono eseguire l'override #roll roll e #add add gestire i campi discontinui. Ad esempio, nel calendario ebraico il mese " Adar I" si verifica solo negli anni bisestili; negli altri anni il calendario passa da Shevat (mese 4) ad Adar (mese 6). I HebrewCalendar#add HebrewCalendar.add metodi e HebrewCalendar#roll HebrewCalendar.roll prendono in considerazione questo, in modo che l'aggiunta di 1 mese a Shevat restituisca il risultato corretto (Adar) in un anno non bisestile. Il metodo #pinField pinField dell'utilità protetta è spesso utile quando si implementano questi due metodi. </li>

</ul>

<big><b>Comportamento< normalizzato/b></big>

Il comportamento di determinati campi è stato reso coerente in tutti i sistemi di calendario e implementato in Calendar.

<ul>

<Li>Time è normalizzato. Anche se alcuni sistemi di calendario passano tra giorni al tramonto o in altri momenti, tutti i calendari ICU4J passano tra giorni a <>mezzanotte</em> della zona locale. Ciò consente a ICU4J di centralizzare i calcoli temporali in Calendar e di mantenere le corrispondenze di base tra i sistemi di calendario. Campi interessati: #AM_PM, #HOUR#HOUR_OF_DAY, #MINUTE, #SECOND, #MILLISECOND, #ZONE_OFFSET, e #DST_OFFSET.</li>

<Il comportamento del DST li>è normalizzato. Il comportamento dell'ora legale viene calcolato allo stesso modo per tutti i sistemi di calendario e dipende dal valore di diversi GregorianCalendar campi: #YEAR, #MONTHe #DAY_OF_MONTH. Di conseguenza, Calendar calcola sempre questi campi, anche per i sistemi di calendario non gregoriani. Questi campi sono disponibili per le sottoclassi.</li>

<le settimane li>sono normalizzate. Anche se le impostazioni locali definiscono la settimana in modo diverso, in termini di giorno in cui viene avviata e la designazione del numero di settimana uno di un mese o di un anno, usano tutti un meccanismo comune. Inoltre, il giorno della settimana ha una definizione semplice e coerente in tutta la storia. Ad esempio, anche se il calendario gregoriano ha introdotto una discontinuità quando è stata introdotta per la prima volta, il giorno della settimana non è stato interrotto. Per questo motivo, i campi #DAY_OF_WEEK, WEEK_OF_YEAR, WEEK_OF_MONTH#DAY_OF_WEEK_IN_MONTH, #DOW_LOCAL, , #YEAR_WOY vengono tutti calcolati in modo coerente nella classe base, in base a #EXTENDED_YEAR, #DAY_OF_YEAR#MONTH, e #DAY_OF_MONTH, calcolati dalla sottoclasse .</li>

</ul>

<big><b>Intervallo< supportato/b></grande>

L'intervallo consentito di Calendar è stato ristretto. GregorianCalendar utilizzato per tentare di supportare l'intervallo di date con valori di millisecondi da Long.MIN_VALUE a Long.MAX_VALUE. Questo ha introdotto costruzioni imbarazzanti (hack) che rallentavano le prestazioni. Ha inoltre introdotto un comportamento non uniforme ai limiti. Il nuovo Calendar protocollo specifica l'intervallo massimo di date supportabili come quelle con numeri di giorno julian di -0x7F000000 a +0x7F000000. Corrisponde agli anni da circa 5.800.000 A.C. a circa 5.800.000 CE. I programmatori devono utilizzare le costanti protette in Calendar per specificare una data estremamente anticipata o estremamente tardiva.

<big><b>Note< generali/b></big>

<ul>

<le implementazioni di li>Calendars sono <em>proleptic</em>. Ad esempio, anche se il calendario gregoriano non è stato istituito fino al XIX secolo, la GregorianCalendar classe supporta date prima dell'inizio storico del calendario estendendo il sistema di calendario indietro nel tempo. Analogamente, l'oggetto HebrewCalendar si estende all'indietro prima dell'inizio del suo periodo in anni zero e negativi. Le sottoclassi non generano eccezioni perché una data precede l'inizio cronologico di un sistema di calendario. Implementano #handleGetLimit invece per restituire limiti appropriati per #YEARi campi , #ERAe così via. Quindi, se il calendario è impostato su non essere lenient, i valori dei campi out-of-range attiveranno un'eccezione.</li>

<le sottoclassi di sistema li>Calendar calcolano un <anno> esteso em</em>. Ciò differisce dal #YEAR campo in quanto varia su tutti i valori integer, inclusi i valori zero e negativi, e incapsula le informazioni del #YEAR campo e di tutti i campi più grandi. Pertanto, per il calendario gregoriano, viene #EXTENDED_YEAR calcolato come ERA==AD ? YEAR : 1-YEAR. Un altro esempio è il conteggio lungo mayan, che ha anni (KUN) e cicli annidati di anni (KATUN e BAKTUN). Il mayan #EXTENDED_YEAR viene calcolato come TUN + 20 * (KATUN + 20 * BAKTUN). La Calendar classe base usa il #EXTENDED_YEAR campo per calcolare i campi correlati alla settimana.</li>

</ul>

per android.icu.util.Calendar.

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dalla e usati in base ai termini descritti in Creative License 2.5 Attribution License.