Calendar Clase

Definición

[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

Herencia

Object

JavaObject

Object

Calendar

Derivado

Android.Icu.Util.CECalendar

Android.Icu.Util.ChineseCalendar

Android.Icu.Util.GregorianCalendar

Android.Icu.Util.HebrewCalendar

Android.Icu.Util.IndianCalendar

Más…

Atributos

RegisterAttribute

Implementaciones

IJavaObject IJavaPeerable ISerializable ICloneable IComparable IDisposable

Comentarios

<strong>[icu enhancement]</strong> ICU's replacement for java.util.Calendar.  Los métodos, los campos y otras funcionalidades específicas de ICU se etiquetan como "<strong>[icu]</strong>".

Calendar es una clase base abstracta para convertir entre un Date objeto y un conjunto de campos enteros como YEAR, MONTH, DAY, HOUR, etc. (Un Date objeto representa un instante específico en el tiempo con precisión de milisegundos. Consulte Date para obtener información sobre la Date clase ).

Subclases de Calendar interpretación según Date las reglas de un sistema de calendario específico. ICU4J contiene varias subclases que implementan diferentes sistemas de calendario internacional.

Al igual que otras clases que distinguen la configuración regional, Calendar proporciona un método de clase, getInstance, para obtener un objeto generalmente útil de este tipo. CalendarEl método de getInstance devuelve un calendario de un tipo adecuado a la configuración regional, cuyos campos de hora se han inicializado con la fecha y hora actuales: <blockquote>

Calendar rightNow = Calendar.getInstance()

</blockquote>

ULocale Cuando usa getInstance, su etiqueta y valor 'calendar' se recuperan si están presentes. Si se proporciona un valor reconocido, se proporciona un calendario y se configura según corresponda. Las etiquetas reconocidas actualmente son "budista", "chino", "coptic", "ethiopic", "gregoriano", "hebreo", "islámico", "islámico-civil", "japonés" y "roc". Por ejemplo: <blockquote>

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

</blockquote> devolverá una instancia de JapaneseCalendar (con las convenciones de en_US durante los días mínimos de la primera semana, el día de inicio de la semana, etc.).

Un Calendar objeto puede generar todos los valores de campo de hora necesarios para implementar el formato de fecha y hora para un idioma y un estilo de calendario concretos (por ejemplo, japonés-gregoriano, Japanese-Traditional). Calendar define el intervalo de valores devueltos por determinados campos, así como su significado. Por ejemplo, el primer mes del año tiene valor MONTH == JANUARY para todos los calendarios. Otros valores se definen mediante la subclase concreta, como ERA y YEAR. Consulte la documentación de campos individuales y la documentación de subclase para obtener más información.

Cuando un Calendar es <lenient></em>, acepta una gama más amplia de valores de campo que produce. Por ejemplo, un leniento GregorianCalendar interpreta MONTH == JANUARY, DAY_OF_MONTH == 32 como 1 de febrero. Un no sensible GregorianCalendar produce una excepción cuando se proporciona una configuración de campo fuera del intervalo. Cuando los calendarios vuelven a calcular los valores de campo para que los devuelva get(), normalizan. Por ejemplo, un GregorianCalendar siempre genera DAY_OF_MONTH valores entre 1 y la longitud del mes.

Calendar define una semana de siete días específica de la configuración regional con dos parámetros: el primer día de la semana y los días mínimos de la primera semana (de 1 a 7). Estos números se toman de los datos de recursos de configuración regional cuando se construye un Calendar . También se pueden especificar explícitamente a través de la API.

Al establecer o obtener los WEEK_OF_MONTH campos o WEEK_OF_YEAR , Calendar debe determinar la primera semana del mes o año como punto de referencia. La primera semana de un mes o año se define como el primer período de siete días que comienza getFirstDayOfWeek() y contiene al menos getMinimalDaysInFirstWeek() días de ese mes o año. Semanas numeradas ..., -1, 0 preceden a la primera semana; semanas numeradas 2, 3,... síguelo. Tenga en cuenta que la numeración normalizada devuelta por get() puede ser diferente. Por ejemplo, una subclase específica Calendar puede designar la semana anterior a la semana 1 de un año como semana <em em><> del año anterior.

Al calcular a Date partir de campos de tiempo, pueden surgir algunas circunstancias especiales: puede que no haya información suficiente para calcular ( Date por ejemplo, solo año y mes, pero ningún día en el mes), puede haber información incoherente (como "Martes, 15 de julio de 1996" -- 15 de julio de 1996 es realmente un lunes), o la hora de entrada podría ser ambigua debido a la transición de zona horaria.

<información insuficiente fuerte>.</strong> El calendario usará información predeterminada para especificar los campos que faltan. Esto puede variar según el calendario; para el calendario gregoriano, el valor predeterminado de un campo es el mismo que el del inicio de la época: es decir, YEAR = 1970, MONTH = JANUARY, DATE = 1, etc.

<información fuerte>incoherente.</strong> Si los campos entran en conflicto, el calendario dará preferencia a los campos establecidos más recientemente. Por ejemplo, al determinar el día, el calendario buscará una de las siguientes combinaciones de campos. Se usará la combinación más reciente, determinada por el campo único establecido más recientemente.

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

Para la hora del día:

<blockquote>

HOUR_OF_DAY
            AM_PM + HOUR

</blockquote>

<fuerte>tiempo de reloj de pared ambiguo.</strong> Cuando ha cambiado el desplazamiento de hora de UTC, genera un intervalo de tiempo ambiguo alrededor de la transición. Por ejemplo, muchas ubicaciones de EE. UU. observan el horario de verano. En la fecha que cambia al horario de verano en EE. UU., la hora del reloj salta de las 12:59 (estándar) a las 2:00 a.m. (verano). Por lo tanto, la hora del reloj de la pared de las 1:00 a las 1:59 am no existe en la fecha. Cuando la hora de la pared de entrada cae en este espacio de tiempo que falta, el calendario de ICU resuelve la hora con el desplazamiento UTC antes de la transición de forma predeterminada. En este ejemplo, 1:30 AM se interpreta como hora estándar de 1:30 AM (no existe), por lo que el resultado final será de 2:30 a. m. hora de verano.

En la fecha que vuelve a la hora estándar, la hora del reloj se mueve una hora a las 2:00 a. m. Por lo tanto, la hora del reloj de la pared de las 1:00 a las 1:59 a. m. se produce dos veces. En este caso, el calendario de ICU resuelve la hora con el desplazamiento UTC después de la transición de forma predeterminada. Por ejemplo, las 1:30 a. m. en la fecha se resuelven como hora estándar de 1:30 a. m.

Las API #setRepeatedWallTimeOption(int) de calendario pueden personalizar comportamientos ambiguos de resolución de tiempo de reloj de reloj y #setSkippedWallTimeOption(int). Estos métodos están disponibles en ICU 49 o versiones posteriores.

<nota fuerte>:</strong> para algunos calendarios no gregorianos, es posible que se necesiten diferentes campos para la desambiguación completa. Por ejemplo, una especificación completa del calendario astronómica árabe historial requiere año, mes, día de mes <y></em> día de la semana en algunos casos.

<nota fuerte>:</fuerte> Hay ciertas ambigüedades posibles en la interpretación de ciertos tiempos singulares, que se resuelven de las siguientes maneras: <ol><li> 24:00:00 "pertenece" al día siguiente. Es decir, 23:59 el 31 de dic, 1969 < 24:00 el 1 de enero de 1970 < 24:01:00 el 1 de enero de 1970

li aunque históricamente no precisa, la medianoche también pertenece a "am", y el mediodía pertenece a "pm", así que el mismo día, 12:00 am (medianoche) < 12:01 am, y 12:00 pm (mediodía) < 12:01 pm /ol

Las cadenas de formato de fecha u hora no forman parte de la definición de un calendario, ya que deben ser modificables o invalidables por el usuario en tiempo de ejecución. Use DateFormat para dar formato a las fechas.

<métodos> de manipulación de campo fuerte</fuerte>

Calendar los campos se pueden cambiar mediante tres métodos: set(), add()y roll().

<campo de cambios fuertes>set(f, value)< o fuertes> en f.value Además, establece una variable miembro interna para indicar que se ha cambiado el campo f . Aunque el campo f se cambia inmediatamente, los milisegundos del calendario no se vuelven a calcular hasta que se realiza la siguiente llamada a get(), getTime()o getTimeInMillis() . Por lo tanto, varias llamadas para set() no desencadenar varios cálculos innecesarios. Como resultado de cambiar un campo mediante set(), otros campos también pueden cambiar, según el campo, el valor del campo y el sistema de calendario. Además, get(f) no devolverá necesariamente value después de que se hayan vuelto a calcular los campos. Los detalles están determinados por la clase de calendario concreta.

<em>Example</em>: Considere un GregorianCalendar valor original establecido en el 31 de agosto de 1999. La llamada set(Calendar.MONTH, Calendar.SEPTEMBER) establece el calendario al 31 de septiembre de 1999. Se trata de una representación interna temporal que se resuelve hasta el 1 de octubre de 1999 si getTime()se llama a continuación. Sin embargo, una llamada a set(Calendar.DAY_OF_MONTH, 30) antes de la llamada a getTime() establece el calendario en el 30 de septiembre de 1999, ya que no se produce ninguna recomputación después set() de sí misma.

<se agrega > fuerteadd(f, delta)<> o fuertedelta al campo .f Esto equivale a llamar set(f, get(f) + delta) a con dos ajustes:

<blockquote>

<strong>Add rule 1</strong>. El valor del campo f después de la llamada menos el valor del campo f antes de la llamada es delta, módulo cualquier desbordamiento que se haya producido en el campo f. El desbordamiento se produce cuando un valor de campo supera su intervalo y, como resultado, el siguiente campo mayor se incrementa o disminuye y el valor del campo se vuelve a ajustar en su intervalo.

<strong>Add rule 2/strong( Agregar regla 2</strong>). Si se espera que un campo más pequeño sea invariable, pero   es imposible que sea igual a su valor anterior debido a los cambios en su mínimo o máximo después de cambiar el campo f , su valor se ajusta para ser lo más cercano posible a su valor esperado. Un campo más pequeño representa una unidad de tiempo más pequeña. HOUR es un campo menor que DAY_OF_MONTH. No se realiza ningún ajuste en campos más pequeños que no se espera que sean invariables. El sistema de calendario determina qué campos se espera que sean invariables.

</blockquote>

Además, a diferencia set()de , add() fuerza una recomputación inmediata de los milisegundos del calendario y todos los campos.

<em>Example</em>: Considere un GregorianCalendar valor original establecido en el 31 de agosto de 1999. La llamada add(Calendar.MONTH, 13) establece el calendario al 30 de septiembre de 2000. <strong>Add rule 1</strong> establece el MONTH campo en septiembre, ya que la adición de 13 meses a agosto da septiembre del próximo año. Puesto que DAY_OF_MONTH no puede ser 31 en septiembre en , GregorianCalendar<la regla de adición fuerte 2>/strong<> establece en DAY_OF_MONTH 30, el valor más cercano posible. Aunque es un campo más pequeño, DAY_OF_WEEK no se ajusta mediante la regla 2, ya que se espera que cambie cuando el mes cambie en .GregorianCalendar

<se agrega > fuerteroll(f, delta)<> o fuertedelta al campo f sin cambiar los campos más grandes. Esto equivale a llamar add(f, delta) a con el siguiente ajuste:

<blockquote>

<regla de roll> fuerte</fuerte>. Los campos más grandes no se modifican después de la llamada. Un campo mayor representa una unidad de tiempo mayor. DAY_OF_MONTH es un campo mayor que HOUR.

</blockquote>

<em>Example</em>: Considere un GregorianCalendar valor original establecido en el 31 de agosto de 1999. La llamada roll(Calendar.MONTH, 8) establece el calendario al 30 de abril de <1999>/strong<>. Agregar regla 1 establece el MONTH campo en abril. El uso de , GregorianCalendarDAY_OF_MONTH no puede ser 31 en el mes de abril. Agregue la regla 2 para establecerla en el valor más cercano posible, 30. Por último, la <>regla< de puesta fuerte/fuerte> mantiene el YEAR valor de campo de 1999.

<em>Example</em>: considere un GregorianCalendar valor original establecido en el domingo 6 de junio de 1999. La llamada roll(Calendar.WEEK_OF_MONTH, -1) establece el calendario al martes 1 de junio de 1999, mientras que la llamada add(Calendar.WEEK_OF_MONTH, -1) establece el calendario al domingo 30 de mayo de 1999. Esto se debe a que la regla roll impone una restricción adicional: no MONTH debe cambiar cuando WEEK_OF_MONTH se implementa . Tomado junto con la regla 1, la fecha resultante debe estar entre el martes 1 de junio y el sábado 5 de junio. Según la regla 2, , DAY_OF_WEEKun invariable al cambiar , WEEK_OF_MONTHse establece en Martes, el valor más cercano posible al domingo (donde domingo es el primer día de la semana).

<modelo de uso> seguro</seguro>. Para motivar el comportamiento de y add(), considere un componente de roll() interfaz de usuario con botones de incremento y decremento para el mes, el día y el año, y un subyacenteGregorianCalendar. Si la interfaz lee el 31 de enero de 1999 y el usuario presiona el botón de incremento de mes, ¿qué debe leer? Si la implementación subyacente usa set(), puede leer el 3 de marzo de 1999. Un mejor resultado sería el 28 de febrero de 1999. Además, si el usuario vuelve a presionar el botón de incremento del mes, debe leer el 31 de marzo de 1999, no el 28 de marzo de 1999. Al guardar la fecha original y usar o add()roll(), dependiendo de si los campos más grandes deben verse afectados, la interfaz de usuario puede comportarse como la mayoría de los usuarios esperarán de forma intuitiva.

<b>Nota:</b> Debe usar #roll roll siempre y #add add en lugar de intentar realizar operaciones aritméticas directamente en los campos de .Calendar Es bastante posible que Calendar las subclases tengan campos con un comportamiento no lineal, por ejemplo, faltan meses o días durante años no bisiestos. Los métodos y add las subclases roll tendrán esto en cuenta, mientras que las manipulaciones aritméticas simples pueden dar resultados no válidos.

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

Recientemente, la implementación de Calendar ha cambiado significativamente para admitir mejor las subclases. La clase original Calendar se diseñó para admitir subclases, pero solo tenía una subclase implementada, GregorianCalendar. Con la implementación de varias subclases de calendario nuevas, incluida BuddhistCalendarla API de subclases , ChineseCalendarHebrewCalendarIslamicCalendar, , y JapaneseCalendar, se ha vuelto a trabajar exhaustivamente. En esta sección se detalla la nueva API de subclases y otras formas en las que android.icu.util.Calendar difiere de java.util.Calendar.

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

Información general sobre los cambios entre la arquitectura clásica Calendar y la nueva arquitectura.

<ul>

<li>La fields[] matriz ahora es private en lugar de protected. Las subclases deben tener acceso a ella mediante los métodos #internalSet y #internalGet. <b>Motivación:</b> Las subclases no deben acceder directamente a los miembros de datos.</li>

<li>La time palabra larga es private ahora en lugar de protected. Las subclases pueden acceder a ella mediante el método #internalGetTimeInMillis, que no provoca una actualización. <b>Motivación:</b> Las subclases no deben acceder directamente a los miembros de datos.</li>

<li>El ámbito de responsabilidad de las subclases se ha reducido drásticamente. La mayor cantidad de funcionalidad posible se implementa en la Calendar clase base. Como resultado, es mucho más fácil subclase Calendar. <b>Motivación:</b> Las subclases no deben tener que volver a implementar el código común. Algunos comportamientos son comunes en todos los sistemas de calendario: la definición y el comportamiento de campos y campos de hora relacionados con la semana, el comportamiento aritmético (#add(int, int) add y #roll(int, int) roll) de muchos campos y el sistema de validación de campos.</li>

<li>La API de subclases se ha rediseñado completamente.</li>

<li>La Calendar clase base contiene cierta compatibilidad algorítmica de calendario gregoriano que las subclases pueden usar (específicamente en #handleComputeFields). Las subclases pueden usar los métodos para obtener valores predefinidos getGregorianXxx() . <b>Motivación:</b> Esto es necesario para todas las Calendar subclases con el fin de implementar un comportamiento coherente de la zona horaria y los sistemas derivados de Gregoriano pueden usar los datos ya calculados.</li>

<li>La FIELD_COUNT constante se ha quitado. Utilice #getFieldCount. Además, se ha agregado la API de marco para permitir que las subclases definan campos adicionales. <b>Motivación: </b>El número de campos no es constante en los sistemas de calendario.</li>

<li>El intervalo de fechas controladas se ha reducido de +/- ~300.000.000 años a +/- ~5.000.000 años. En términos prácticos, esto no debería afectar a los clientes. Sin embargo, significa que el código de cliente no se puede garantizar resultados bien comportados con fechas como Date(Long.MIN_VALUE) o Date(Long.MAX_VALUE). En su lugar, se deben usar las Calendar constantes protegidas. <b Motivación:>/b< Con la adición del > campo, los números de día juliano deben restringirse a un valor de 32 bits #JULIAN_DAY.int Esto restringe el intervalo admitido general. Además, restringir el intervalo admitido simplifica los cálculos mediante la eliminación del código de caso especial que se usó para dar cabida al desbordamiento aritmético en milis cerca Long.MIN_VALUE de y Long.MAX_VALUE.</li>

<li>Nuevos campos se implementan: #JULIAN_DAY define la especificación de un solo campo de la fecha. #MILLISECONDS_IN_DAY define una especificación de campo único del tiempo de pared. #DOW_LOCAL e #YEAR_WOY implemente el comportamiento localizado del día de la semana y la semana del año.</li>

<li>Subclases puede acceder a las constantes de milisegundos protegidas definidas en Calendar.</li>

<li>New API se ha agregado para admitir subclases específicas del calendario de DateFormat.</li>

<li>Se han implementado varias subclases, que representan varios sistemas de calendario internacionales.</li>

</ul>

<big><b>Subclase API</b></big>

La API original Calendar se basaba en la experiencia de implementar una sola subclase, GregorianCalendar. Como resultado, no se habían solucionado todos los kinks de subclase. La nueva API de subclases se ha refinado en función de varias subclases implementadas. Esto incluye métodos que se deben invalidar y métodos para que las subclases llamen. Las subclases ya no tienen acceso directo a fields y stamp. En su lugar, tienen una nueva API para acceder a ellas. Las subclases pueden asignar la fields matriz a través de un método de marco protegido; esto permite que las subclases especifiquen campos adicionales.

Se ha movido más funcionalidad a la clase base. La clase base ahora contiene gran parte de la maquinaria computacional para admitir el calendario gregoriano. Esto se basa en dos cosas: (1) Muchos calendarios se basan en el calendario gregoriano (como los calendarios budistas y japoneses imperiales). (2) <Los>calendarios all</em> requieren compatibilidad básica gregoriana con el fin de controlar los cálculos de zona horaria.

Los cálculos comunes se han movido a Calendar. Las subclases ya no calculan los campos relacionados con la semana y los campos relacionados con la hora. Normalmente se controlan para todos los calendarios mediante la clase base.

<b>Cálculo de subclase de campos=> de tiempo</b>

Los #ERAcampos , #YEAR, #EXTENDED_YEAR, #MONTH, #DAY_OF_MONTHy #DAY_OF_YEAR se calculan mediante la subclase, en función del día juliano. Todos los demás campos se calculan mediante Calendar.

<ul>

<las subclases li>deben implementarse #handleComputeFields para calcular los #ERAcampos , #YEAR, #EXTENDED_YEAR#MONTH, , #DAY_OF_MONTHy #DAY_OF_YEAR , en función del valor del #JULIAN_DAY campo. Si hay campos específicos del calendario no definidos por Calendar, también deben calcularse. Estos son los únicos campos que la subclase debe calcular. Todos los demás campos se calculan mediante la clase base, por lo que los campos de hora y semana se comportan de forma coherente en todos los calendarios. La versión predeterminada de este método en Calendar implementa un calendario gregoriano proleptico. Dentro de este método, las subclases pueden llamar getGregorianXxx() a para obtener el mes natural gregoriano, el día del mes y el año extendido para la fecha especificada.</li>

</ul>

<b>Cálculo de subclase de campos => time</b>

La interpretación de la mayoría de los valores de campo se controla completamente mediante Calendar. Calendar determina qué campos se establecen, que no, que se establecen más recientemente, etc. Además, Calendar controla el cálculo del tiempo desde los campos de tiempo y controla los campos relacionados con la semana. Lo único que debe hacer la subclase es determinar el año extendido, en función de los campos de año y, a continuación, dado un año extendido y un mes, debe devolver un número de día juliano.

<ul>

<li>Subclases debe implementar #handleGetExtendedYear para devolver el año extendido para este sistema de calendario, en función de los #YEARcampos , #EXTENDED_YEARy los campos que use el sistema de calendario que sean mayores de un año, como #ERA.</li>

<li>Subclasses debe implementar #handleComputeMonthStart para devolver el número de día juliano asociado a un mes y un año extendido. Este es el número de días julianos del día anterior al primer día del mes. El número de mes está basado en cero. Este cálculo no debe depender de ningún valor de campo.</li>

</ul>

<b>Otros métodos</b>

<ul>

<li>Subclases debe implementar #handleGetMonthLength para devolver el número de días en un mes determinado de un año extendido determinado. El número de mes, como siempre, es de base cero.</li>

<li>Subclases debe implementar #handleGetYearLength para devolver el número de días del año extendido especificado. Este método lo usa computeWeekFields para calcular los #WEEK_OF_YEAR campos y #YEAR_WOY .</li>

<li>Subclases debe implementar #handleGetLimit para devolver los valores protegidos de un campo, en función del valor de limitType. Este método solo necesita controlar los campos #ERA, , #YEAR, #MONTH#WEEK_OF_YEAR#WEEK_OF_MONTH#DAY_OF_MONTH#DAY_OF_YEAR, , #DAY_OF_WEEK_IN_MONTH, , y . #YEAR_WOY#EXTENDED_YEAR Otros campos son invariables (con respecto al sistema de calendario) y se controlan mediante la clase base.</li>

<Li>Opcionalmente, las subclases pueden invalidar #validateField para comprobar cualquier campo específico de la subclase. Si el valor del campo está fuera del intervalo, el método debe producir una IllegalArgumentExceptionexcepción . El método puede llamar super.validateField(field) a para controlar campos de forma genérica, es decir, para compararlos con el intervalo getMinimum(field)..getMaximum(field).</li>

<Li>Opcionalmente, las subclases pueden invalidar #handleCreateFields para crear una int[] matriz lo suficientemente grande como para contener los campos del calendario. Esto solo es necesario si el calendario define campos adicionales más allá de los definidos por Calendar. La longitud del resultado debe estar entre los recuentos de campos base y máximo.</li>

<Li>Opcionalmente, las subclases pueden invalidar #handleGetDateFormat para crear un DateFormat adecuado para este calendario. Esto solo es necesario si una subclase de calendario vuelve a definir el uso de un campo (por ejemplo, cambia el #ERA campo de un campo simbólico a uno numérico) o define un campo adicional.</li>

<Li>Opcionalmente, las subclases pueden invalidar #roll roll y #add add controlar campos que no son discontinuos. Por ejemplo, en el calendario hebreo el mes " Adar I" sólo ocurre en años bisiestos; en otros años, el calendario salta de Shevat (mes n.º 4) a Adar (mes n.º 6). Los HebrewCalendar#add HebrewCalendar.add métodos y HebrewCalendar#roll HebrewCalendar.roll tienen esto en cuenta, de modo que agregar 1 mes a Shevat da el resultado adecuado (Adar) en un año no bisiesto. El método #pinField pinField de utilidad protegido suele ser útil al implementar estos dos métodos. </li>

</ul>

<big><b>Comportamiento< normalizado/b></big>

El comportamiento de determinados campos se ha hecho coherente en todos los sistemas de calendario e implementado en Calendar.

<ul>

<li>Time se normaliza. Aunque algunos sistemas de calendario pasan entre días a la puesta de sol o en otras ocasiones, todos los calendarios de ICU4J pasan entre días en <la>zona local medianoche</em>. Esto permite a ICU4J centralizar los cálculos de tiempo en Calendar y mantener correspondencias básicas entre sistemas de calendario. Campos afectados: #AM_PM, #HOUR, #HOUR_OF_DAY, #MINUTE#SECOND, #MILLISECOND, , #ZONE_OFFSETy #DST_OFFSET.</li>

<Se normaliza el comportamiento de li>DST. El comportamiento del horario de verano se calcula igual para todos los sistemas de calendario y depende del valor de varios GregorianCalendar campos: , #YEAR#MONTHy #DAY_OF_MONTH. Como resultado, Calendar siempre calcula estos campos, incluso para sistemas de calendario no gregorianos. Estos campos están disponibles para las subclases.</li>

<li>Semanas se normalizan. Aunque las configuraciones regionales definen la semana de forma diferente, en términos del día en el que se inicia y la designación de la semana número uno de un mes o año, todos usan un mecanismo común. Además, el día de la semana tiene una definición simple y coherente a lo largo de la historia. Por ejemplo, aunque el calendario gregoriano introdujo una discontinuidad cuando se instituyó por primera vez, el día de la semana no se interrumpió. Por este motivo, los campos #DAY_OF_WEEK, WEEK_OF_YEAR, WEEK_OF_MONTH, #DAY_OF_WEEK_IN_MONTH, #DOW_LOCAL#YEAR_WOY se calculan de forma coherente en la clase base, en función de los #EXTENDED_YEARelementos , #DAY_OF_YEAR, #MONTHy #DAY_OF_MONTH, que la subclase calcula.</li>

</ul>

<big><b>Intervalo admitido</b></big>

El intervalo permitido de Calendar se ha reducido. GregorianCalendar se usa para intentar admitir el intervalo de fechas con valores de milisegundos de Long.MIN_VALUE a Long.MAX_VALUE. Esto introdujo construcciones raras (hacks) que ralentizaron el rendimiento. También introdujo un comportamiento no uniforme en los límites. El nuevo Calendar protocolo especifica el intervalo máximo de fechas compatibles que tienen números de día juliano de -0x7F000000 a +0x7F000000. Esto corresponde a años de ~5.800.000 BCE a ~5.800.000 CE. Los programadores deben usar las constantes protegidas en Calendar para especificar una fecha extremadamente temprana o extremadamente tardía.

<big><b>General notes</b></big>

<ul>

<las implementaciones de calendarios li>son <em>proleptic</em>. Por ejemplo, aunque el calendario gregoriano no se instituyó hasta el siglo XIX, la GregorianCalendar clase admite fechas antes del inicio histórico del calendario al extender el sistema de calendario hacia atrás en el tiempo. Del mismo modo, el HebrewCalendar se extiende hacia atrás antes del inicio de su época en cero y años negativos. Las subclases no inician excepciones porque una fecha precede al inicio histórico de un sistema de calendario. En su lugar, implementan #handleGetLimit para devolver los límites adecuados en #YEARlos campos , #ERA, etc. A continuación, si el calendario está establecido para que no sea flexible, los valores de campo fuera del intervalo desencadenarán una excepción.</li>

<li>Calendar system subclases compute a <em>extended year</em>. Esto difiere del #YEAR campo en que abarca todos los valores enteros, incluidos los valores cero y negativos, y encapsula la información del #YEAR campo y todos los campos más grandes. Por lo tanto, para el calendario gregoriano, se #EXTENDED_YEAR calcula como ERA==AD ? YEAR : 1-YEAR. Otro ejemplo es el recuento maya largo, que tiene años (KUN) y ciclos anidados de años (KATUN y BAKTUN). El maya #EXTENDED_YEAR se calcula como TUN + 20 * (KATUN + 20 * BAKTUN). La Calendar clase base usa el #EXTENDED_YEAR campo para calcular los campos relacionados con la semana.</li>

</ul>

Java documentación para android.icu.util.Calendar.

Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el Android y se usan según los términos descritos en creative Creative Commons 2.5 Attribution License.