Calendar Classe

Definição

[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

Herança

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

Mais…

Atributos

RegisterAttribute

Implementações

IJavaObject IJavaPeerable ISerializable ICloneable IComparable IDisposable

Comentários

<strong>[icu enhancement]</strong> ICU's replacement for java.util.Calendar.  Métodos, campos e outras funcionalidades específicas da UTI são rotulados como '<strong>[icu]</strong>'.

Calendar é uma classe base abstrata para converter entre um Date objeto e um conjunto de campos inteiros, como YEAR, MONTH, DAYe HOURassim por diante. (Um Date objeto representa um instante específico no tempo com precisão de milissegundos. Consulte Date informações sobre a Date classe.)

Subclasses de interpretação de Calendar acordo Date com as regras de um sistema de calendário específico. O ICU4J contém várias subclasses implementando diferentes sistemas de calendário internacionais.

Assim como outras classes sensíveis à localidade, Calendar fornece um método getInstancede classe para obter um objeto geralmente útil desse tipo. Calendar's getInstance method returns a calendar of a type appropriate to the locale, whose time fields have been initialized with the current date and time: <blockquote>

Calendar rightNow = Calendar.getInstance()

</blockquote>

Quando um ULocale é usado por getInstance, sua marca 'calendar' e valor são recuperados se presentes. Se um valor reconhecido for fornecido, um calendário será fornecido e configurado conforme apropriado. Atualmente, as marcas reconhecidas são "budista", "chinês", "copta", "etépico", "gregoriano", "hebraico", "islâmico", "islâmico-civil", "japonês" e "roc". Por exemplo: <blockquote>

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

</blockquote> retornará uma instância de JapaneseCalendar (usando convenções de en_US para dias mínimos na primeira semana, dia de início da semana, etc.).

Um Calendar objeto pode produzir todos os valores de campo de tempo necessários para implementar a formatação de data e hora para um determinado idioma e estilo de calendário (por exemplo, japonês-gregoriano, Japanese-Traditional). Calendar define o intervalo de valores retornados por determinados campos, bem como seu significado. Por exemplo, o primeiro mês do ano tem valor MONTH == JANUARY para todos os calendários. Outros valores são definidos pela subclasse concreta, como ERA e YEAR. Consulte a documentação de campo individual e a documentação de subclasse para obter detalhes.

Quando um Calendar é <em>lenient</em>, ele aceita uma gama mais ampla de valores de campo do que produz. Por exemplo, uma interpretaçãoGregorianCalendarMONTH == branda JANUARY , DAY_OF_MONTH == 32 como 1º de fevereiro. Uma não branda GregorianCalendar gera uma exceção quando determinadas configurações de campo fora do intervalo. Quando os calendários recompõem valores de campo para serem retornados, get()eles os normalizam. Por exemplo, um GregorianCalendar sempre produz DAY_OF_MONTH valores entre 1 e o comprimento do mês.

Calendar define uma semana de sete dias específica da localidade usando dois parâmetros: o primeiro dia da semana e os dias mínimos na primeira semana (de 1 a 7). Esses números são obtidos dos dados de recurso de localidade quando um Calendar é construído. Eles também podem ser especificados explicitamente por meio da API.

Ao definir ou obter o WEEK_OF_MONTH ou WEEK_OF_YEAR campos, Calendar deve determinar a primeira semana do mês ou ano como um ponto de referência. A primeira semana de um mês ou ano é definida como o primeiro período de sete dias que começa getFirstDayOfWeek() e contém pelo menos getMinimalDaysInFirstWeek() dias desse mês ou ano. Semanas numeradas ..., -1, 0 precedem a primeira semana; semanas numeradas 2, 3,... siga-o. Observe que a numeração normalizada retornada pode get() ser diferente. Por exemplo, uma subclasse específica Calendar pode designar a semana anterior à semana 1 de um ano como semana <em>n</em> do ano anterior.

Ao calcular um de Date campos de tempo, algumas circunstâncias especiais podem surgir: pode haver informações insuficientes para calcular o Date (como apenas ano e mês, mas nenhum dia no mês), pode haver informações inconsistentes (como "terça-feira, 15 de julho de 1996" -- 15 de julho de 1996 é na verdade uma segunda-feira), ou o tempo de entrada pode ser ambíguo por causa da transição de fuso horário.

<informações insuficientes fortes>.</strong> O calendário usará informações padrão para especificar os campos ausentes. Isso pode variar de acordo com o calendário; para o calendário gregoriano, o padrão para um campo é o mesmo do início da época: ou seja, ANO = 1970, MÊS = JANEIRO, DATA = 1, etc.

<informações inconsistentes fortes>.</strong> Se os campos entrarem em conflito, o calendário dará preferência aos campos definidos mais recentemente. Por exemplo, ao determinar o dia, o calendário procurará uma das seguintes combinações de campos. A combinação mais recente, conforme determinado pelo campo único definido mais recentemente, será usada.

<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 a hora do dia:

<blockquote>

HOUR_OF_DAY
            AM_PM + HOUR

</blockquote>

<tempo forte>do relógio de parede ambíguo.</strong> Quando o deslocamento de tempo de UTC foi alterado, ele produz um intervalo de tempo ambíguo em torno da transição. Por exemplo, muitos locais dos EUA observam o horário de verão. Na data de mudança para o horário de verão nos EUA, o horário do relógio de parede salta das 00h59 (padrão) para as 2:00 da manhã (luz do dia). Portanto, o horário do relógio de parede das 1h às 1h59 não existe na data. Quando o tempo de parede de entrada cai nesse intervalo de tempo ausente, o Calendário da UTI resolve o tempo usando o deslocamento UTC antes da transição por padrão. Neste exemplo, 1:30 am é interpretado como 1:30 am hora padrão (não existe), portanto, o resultado final será 2:30 am horário de verão.

Na data de mudança de volta para a hora padrão, o horário do relógio de parede é movido para trás uma hora às 2:00 da manhã. Portanto, o horário do relógio de parede de 1:00 às 1:59 da manhã ocorre duas vezes. Nesse caso, o Calendário da UTI resolve o tempo usando o deslocamento UTC após a transição por padrão. Por exemplo, 1:30 da manhã na data é resolvida como hora padrão 1:30.

Comportamentos ambíguos de resolução de tempo de relógio de parede podem ser personalizados por APIs #setRepeatedWallTimeOption(int) de calendário e #setSkippedWallTimeOption(int). Esses métodos estão disponíveis na UTI 49 ou versões posteriores.

<Observação forte>:</forte> para alguns calendários não gregorianos, campos diferentes podem ser necessários para a desambiguação completa. Por exemplo, uma especificação completa do calendário astronômico árabe historial requer ano, mês, dia do mês <>em e</em> dia da semana em alguns casos.

<Observação forte>:/strong< Há certas ambiguidades possíveis na interpretação de determinados tempos singulares, que são resolvidos das seguintes maneiras: >ol<>li< 24:00:00 "pertence"> ao dia seguinte. Ou seja, 23:59 em 31 de dez de 1969 < 24:00 em 1º de janeiro de 1970 > 24:01:00 em 1º de janeiro de 1970

li Embora historicamente não seja preciso, meia-noite também pertence a "am", e o meio-dia pertence a "pm", portanto, no mesmo dia, 12:00 am (meia-noite) < 12:01 am, e 12:00 pm (meio-dia) < 12:01 pm /ol

As cadeias de caracteres de formato de data ou hora não fazem parte da definição de um calendário, pois elas devem ser modificáveis ou substituíveis pelo usuário em runtime. Use DateFormat para formatar datas.

<métodos fortes>de manipulação de campo</forte>

Calendar os campos podem ser alterados usando três métodos: set(), add()e roll().

<campo de alterações > fortesset(f, value)<>/fortesf para .value Além disso, ele define uma variável de membro interna para indicar que o campo f foi alterado. Embora o campo f seja alterado imediatamente, os milissegundos do calendário não são recomputados até que a próxima chamada seja get()getTime()feita ou getTimeInMillis() feita. Portanto, várias chamadas para set() não disparar várias computações desnecessárias. Como resultado da alteração de um campo usando set(), outros campos também podem mudar, dependendo do campo, do valor do campo e do sistema de calendário. Além disso, get(f) não retornará necessariamente value depois que os campos forem recomputados. As especificidades são determinadas pela classe de calendário concreta.

<em>Exemplo</em>: considere um GregorianCalendar originalmente definido como 31 de agosto de 1999. A chamada set(Calendar.MONTH, Calendar.SEPTEMBER) define o calendário como 31 de setembro de 1999. Essa é uma representação interna temporária que é resolvida para 1º de outubro de 1999, se getTime()então for chamada. No entanto, uma chamada para set(Calendar.DAY_OF_MONTH, 30) antes da chamada para getTime() definir o calendário como 30 de setembro de 1999, já que nenhuma recomputação ocorre após set() si mesma.

<forte>add(f, delta)</forte> adiciona delta ao campo f. Isso é equivalente à chamada set(f, get(f) + delta) com dois ajustes:

<blockquote>

<strong>Add rule 1</strong>. O valor do campo f após a chamada menos o valor do campo f antes da chamada ser delta, modulo qualquer estouro que tenha ocorrido no campo f. O estouro ocorre quando um valor de campo excede seu intervalo e, como resultado, o próximo campo maior é incrementado ou decréscimo e o valor do campo é ajustado novamente em seu intervalo.

<strong>Add rule 2</strong>. Se espera-se que um campo menor seja invariável, mas   é impossível que ele seja igual ao valor anterior devido a alterações no mínimo ou no máximo após a alteração do campo f e, em seguida, seu valor é ajustado para ser o mais próximo possível de seu valor esperado. Um campo menor representa uma unidade de tempo menor. HOUR é um campo menor que DAY_OF_MONTH. Nenhum ajuste é feito em campos menores que não devem ser invariáveis. O sistema de calendário determina quais campos devem ser invariáveis.

</blockquote>

Além disso, ao contrário set(), add() força uma recomputação imediata dos milissegundos do calendário e de todos os campos.

<em>Exemplo</em>: considere um GregorianCalendar originalmente definido como 31 de agosto de 1999. A chamada add(Calendar.MONTH, 13) define o calendário como 30 de setembro de 2000. <strong>Add rule 1</strong> define o MONTH campo para setembro, uma vez que adicionar 13 meses a agosto dá setembro do próximo ano. Como DAY_OF_MONTH não pode ser 31 em setembro em uma GregorianCalendar<regra de adição forte>2</strong> define como DAY_OF_MONTH 30, o valor mais próximo possível. Embora seja um campo menor, DAY_OF_WEEK não é ajustado pela regra 2, pois espera-se que ele mude quando o mês for alterado em um GregorianCalendar.

<adiciona forte>roll(f, delta)</forte >delta ao campo f sem alterar campos maiores. Isso é equivalente à chamada add(f, delta) com o seguinte ajuste:

<blockquote>

<regra roll forte>/forte<.> Campos maiores são inalterados após a chamada. Um campo maior representa uma unidade de tempo maior. DAY_OF_MONTH é um campo maior que HOUR.

</blockquote>

<em>Exemplo</em>: considere um GregorianCalendar originalmente definido como 31 de agosto de 1999. A chamada roll(Calendar.MONTH, 8) define o calendário como 30 de abril, <forte>1999</forte>. Adicionar a regra 1 define o MONTH campo como abril. Usando um GregorianCalendar, o DAY_OF_MONTH não pode ser 31 no mês de abril. Adicionar a regra 2 define-a para o valor mais próximo possível, 30. Por fim, a <regra> de rolagem forte</forte> mantém o YEAR valor do campo de 1999.

<em>Exemplo</em>: considere um GregorianCalendar originalmente definido como domingo, 6 de junho de 1999. A chamada roll(Calendar.WEEK_OF_MONTH, -1) define o calendário como terça-feira, 1º de junho de 1999, enquanto a chamada add(Calendar.WEEK_OF_MONTH, -1) define o calendário para domingo, 30 de maio de 1999. Isso ocorre porque a regra de rolagem impõe uma restrição adicional: não MONTH deve ser alterada quando ela WEEK_OF_MONTH é rolada. Juntamente com a regra de adição 1, a data resultante deve ser entre terça-feira, 1º de junho e sábado, 5 de junho. De acordo com a regra de adição 2, o DAY_OF_WEEK, invariável ao alterar o WEEK_OF_MONTH, é definido como terça-feira, o valor mais próximo possível para domingo (onde domingo é o primeiro dia da semana).

<modelo> de uso forte</forte>. Para motivar o comportamento de eadd(), considere um componente de interface do roll() usuário com botões de incremento e decremento para o mês, dia e ano, e um subjacenteGregorianCalendar. Se a interface ler 31 de janeiro de 1999 e o usuário pressionar o botão de incremento do mês, o que ela deve ler? Se a implementação subjacente for usada set(), ela poderá ler 3 de março de 1999. Um resultado melhor seria 28 de fevereiro de 1999. Além disso, se o usuário pressionar o botão de incremento do mês novamente, ele deverá ler 31 de março de 1999, não 28 de março de 1999. Salvando a data original e usando ou add()roll(), dependendo se campos maiores devem ser afetados, a interface do usuário pode se comportar como a maioria dos usuários espera intuitivamente.

<b>Observação:</b> Você sempre deve usar #roll roll e #add add , em vez de tentar executar operações aritméticas diretamente nos campos de um Calendar. É bem possível que Calendar subclasses tenham campos com comportamento não linear, por exemplo, meses ou dias ausentes durante anos não bissextos. As subclasses add e roll os métodos levarão isso em conta, enquanto manipulações aritméticas simples podem fornecer resultados inválidos.

<Arquitetura de calendário big><><b>na ICU4J</b></big></big>

Recentemente, a implementação de Calendar mudou significativamente para dar melhor suporte à subclasse. A classe original Calendar foi projetada para dar suporte à subclasse, mas tinha apenas uma subclasse implementada. GregorianCalendar Com a implementação de várias novas subclasses de calendário, incluindo a BuddhistCalendarChineseCalendarHebrewCalendarIslamicCalendarJapaneseCalendarAPI de subclasse de subclasse foi retrabalhada minuciosamente. Esta seção detalha a nova API de subclasse e outras maneiras de android.icu.util.Calendar diferenciar .java.util.Calendar

<Big><b>Alterações</b></big>

Visão geral das alterações entre a arquitetura clássica Calendar e a nova arquitetura.

<ul>

<li>A fields[] matriz agora está private em vez de protected. As subclasses devem acessá-la usando os métodos #internalSet e #internalGet. <b>As subclasses de motivação:</b> não devem acessar diretamente os membros de dados.</li>

<li>A time palavra longa agora é private em vez de protected. As subclasses podem acessá-lo usando o método #internalGetTimeInMillis, o que não provoca uma atualização. <b>As subclasses de motivação:</b> não devem acessar diretamente os membros de dados.</li>

<li>O escopo da responsabilidade das subclasses foi drasticamente reduzido. O máximo de funcionalidade possível é implementado na Calendar classe base. Como resultado, é muito mais fácil subclasse Calendar. <b>Motivação:</b> Subclasses não devem ter que reimplementar código comum. Determinados comportamentos são comuns em sistemas de calendário: a definição e o comportamento de campos e campos de tempo relacionados à semana, o comportamento aritmético (#add(int, int) add e #roll(int, int) roll) de muitos campos e o sistema de validação de campo.</li>

<li>A API de subclasse foi completamente reprojetada.</li>

<li>A Calendar classe base contém algum suporte algorítmico de calendário gregoriano que as subclasses podem usar (especificamente em #handleComputeFields). As subclasses podem usar os métodos getGregorianXxx() para obter valores pré-compilados. <b>Motivação:</b> Isso é exigido por todas as Calendar subclasses para implementar um comportamento de fuso horário consistente e os sistemas derivados de Gregoriano podem usar os dados já computados.</li>

<li>A FIELD_COUNT constante foi removida. Use #getFieldCount. Além disso, a API da estrutura foi adicionada para permitir que subclasses definam campos adicionais. <b>Motivação: </b>O número de campos não é constante entre sistemas de calendário.</li>

<li>O intervalo de datas tratadas foi restringido de +/- ~300.000.000 anos para +/- ~5.000.000 anos. Em termos práticos, isso não deve afetar os clientes. No entanto, isso significa que o código do cliente não pode ter resultados bem comportados garantidos com datas como Date(Long.MIN_VALUE) ou Date(Long.MAX_VALUE). Em vez disso, as Calendar constantes protegidas devem ser usadas. <b>Motivação:</b> Com a adição do campo, os #JULIAN_DAY números do dia de Juliano devem ser restritos a um 32 bits int. Isso restringe o intervalo geral com suporte. Além disso, restringir o intervalo com suporte simplifica os cálculos removendo o código de maiúsculas e minúsculas especial que foi usado para acomodar o estouro aritmético em mililitros próximos Long.MIN_VALUE e Long.MAX_VALUE.</li>

<li>Novos campos são implementados: #JULIAN_DAY define a especificação de campo único da data. #MILLISECONDS_IN_DAY define uma especificação de campo único do tempo de parede. #DOW_LOCAL e #YEAR_WOY implemente o comportamento localizado do dia da semana e da semana do ano.</li>

<As subclasses li>podem acessar constantes de milissegundos protegidas definidas em Calendar.</li>

< >li Nova API foi adicionada para dar suporte a subclasses específicas do calendário de DateFormat.</li>

<li>Várias subclasses foram implementadas, representando vários sistemas de calendário internacionais.</li>

</ul>

<API>< de Subclasse big>b</b></big>

A API original Calendar foi baseada na experiência de implementar apenas uma única subclasse. GregorianCalendar Como resultado, todas as dobras de subclasse não tinham sido trabalhadas. A nova API de subclasse foi refinada com base em várias subclasses implementadas. Isso inclui métodos que devem ser substituídos e métodos para que subclasses chamem. As subclasses não têm mais acesso direto a fields e stamp. Em vez disso, eles têm uma nova API para acessá-las. As subclasses são capazes de alocar a fields matriz por meio de um método de estrutura protegido; isso permite que as subclasses especifiquem campos adicionais.

Mais funcionalidade foi movida para a classe base. A classe base agora contém grande parte do maquinário computacional para dar suporte ao calendário gregoriano. Isso se baseia em duas coisas: (1) Muitos calendários são baseados no calendário gregoriano (como os calendários imperial budistas e japoneses). (2) <em>Calendários All</em> exigem suporte gregoriano básico para lidar com cálculos de fuso horário.

Cálculos comuns foram movidos para Calendar. As subclasses não computam mais os campos relacionados à semana e os campos relacionados ao tempo. Geralmente, elas são tratadas para todos os calendários pela classe base.

<b>Computação de subclasse de campos=> de tempo</b>

Os #ERAcampos , #YEAR, #EXTENDED_YEAR, #MONTH#DAY_OF_MONTHe #DAY_OF_YEAR são computados pela subclasse, com base no dia do Juliano. Todos os outros campos são computados por Calendar.

<ul>

<as subclasses li>devem ser implementadas #handleComputeFields para calcular os #ERAcampos, , #YEAR, #EXTENDED_YEAR#MONTH#DAY_OF_MONTHe #DAY_OF_YEAR , com base no valor do #JULIAN_DAY campo. Se houver campos específicos do calendário não definidos, Calendareles também deverão ser computados. Esses são os únicos campos que a subclasse deve computar. Todos os outros campos são computados pela classe base, portanto, os campos de hora e semana se comportam de forma consistente em todos os calendários. A versão padrão desse método implementa Calendar um calendário gregoriano proleptico. Dentro desse método, as subclasses podem chamar getGregorianXxx() para obter o mês do calendário gregoriano, o dia do mês e o ano estendido para a data determinada.</li>

</ul>

<b>Computação de subclasse de tempo=> de campos</b>

A interpretação da maioria dos valores de campo é tratada inteiramente por Calendar. Calendar determina quais campos estão definidos, quais não são, que são definidos mais recentemente e assim por diante. Além disso, Calendar manipula a computação do tempo dos campos de tempo e manipula os campos relacionados à semana. A única coisa que a subclasse deve fazer é determinar o ano estendido, com base nos campos do ano, e então, dado um ano estendido e um mês, ele deve retornar um número de dia juliano.

<ul>

<as subclasses li>devem implementar #handleGetExtendedYear para retornar o ano estendido para este sistema de calendário, com base no #YEAR, #EXTENDED_YEARe em todos os campos que o sistema de calendário usa que são maiores que um ano, como #ERA.</li>

<as subclasses li>devem ser implementadas #handleComputeMonthStart para retornar o número de dia juliano associado a um mês e um ano estendido. Este é o número do dia juliano do dia anterior ao primeiro dia do mês. O número do mês é baseado em zero. Essa computação não deve depender de nenhum valor de campo.</li>

</ul>

<b>Outros métodos</b>

<ul>

<as subclasses li>devem implementar #handleGetMonthLength para retornar o número de dias em um determinado mês de um determinado ano estendido. O número do mês, como sempre, é baseado em zero.</li>

<as subclasses li>devem ser implementadas #handleGetYearLength para retornar o número de dias no ano estendido determinado. Esse método é usado para computeWeekFields calcular os campos e #WEEK_OF_YEAR os #YEAR_WOY campos.</li>

<as subclasses li>devem ser implementadas #handleGetLimit para retornar os valores protegidos de um campo, dependendo do valor de limitType. Esse método só precisa lidar com os campos #ERA, , #YEAR, #MONTH, #WEEK_OF_YEAR, #WEEK_OF_MONTH, #DAY_OF_MONTH, #DAY_OF_YEAR, , #DAY_OF_WEEK_IN_MONTH, #YEAR_WOYe #EXTENDED_YEAR. Outros campos são invariáveis (em relação ao sistema de calendário) e são tratados pela classe base.</li>

<li>Opcionalmente, as subclasses podem substituir #validateField para verificar os campos específicos de subclasse. Se o valor do campo estiver fora do intervalo, o método deverá gerar um IllegalArgumentException. O método pode chamar super.validateField(field) para manipular campos de maneira genérica, ou seja, para compará-los com o intervalo getMinimum(field)..getMaximum(field).</li>

<li>Opcionalmente, as subclasses podem substituir #handleCreateFields para criar uma int[] matriz grande o suficiente para manter os campos do calendário. Isso só será necessário se o calendário definir campos adicionais além daqueles definidos por Calendar. O comprimento do resultado deve estar entre as contagens de campo base e máxima.</li>

<li>Opcionalmente, as subclasses podem substituir #handleGetDateFormat para criar um DateFormat apropriado para este calendário. Isso só será necessário se uma subclasse de calendário redefinir o uso de um campo (por exemplo, alterar o #ERA campo de um campo simbólico para um numérico) ou definir um campo adicional.</li>

<li>Opcionalmente, as subclasses podem substituir #roll roll e #add add manipular campos descontinuados. Por exemplo, no calendário hebraico o mês &aspas; Adar I" ocorre apenas em anos bissextos; em outros anos, o calendário salta de Shevat (mês nº 4) para Adar (mês nº 6). Os HebrewCalendar#add HebrewCalendar.add métodos e levam HebrewCalendar#roll HebrewCalendar.roll isso em conta, de modo que a adição de 1 mês ao Shevat dê o resultado adequado (Adar) em um ano não bissexto. O método #pinField pinField utilitário protegido geralmente é útil ao implementar esses dois métodos. </li>

</ul>

<Comportamento>< normalizado do big>b</b></big>

O comportamento de determinados campos tornou-se consistente em todos os sistemas de calendário e implementado em Calendar.

<ul>

<Li>Time é normalizado. Mesmo que alguns sistemas de calendário transitem entre dias ao pôr do sol ou em outras ocasiões, todos os calendários ICU4J fazem a transição entre os dias na <>zona local meia-noite</em>. Isso permite que o ICU4J centralize os cálculos Calendar de tempo e mantenha correspondências básicas entre sistemas de calendário. Campos afetados: #AM_PM, , #HOUR, #HOUR_OF_DAY, #MINUTE, #SECOND, #MILLISECOND, , #ZONE_OFFSETe #DST_OFFSET.</li>

<O comportamento de li>DST é normalizado. O comportamento do horário de verão é computado da mesma forma para todos os sistemas de calendário e depende do valor de vários GregorianCalendar campos: o #YEAR, #MONTHe #DAY_OF_MONTH. Como resultado, Calendar sempre computa esses campos, mesmo para sistemas de calendário não gregorianos. Esses campos estão disponíveis para subclasses.</li>

<Li>Weeks são normalizadas. Embora as localidades definam a semana de forma diferente, em termos do dia em que ela começa, e a designação da semana número um de um mês ou ano, todas elas usam um mecanismo comum. Além disso, o dia da semana tem uma definição simples e consistente ao longo da história. Por exemplo, embora o calendário gregoriano tenha introduzido uma descontinuidade quando instituída pela primeira vez, o dia da semana não foi interrompido. Por esse motivo, os campos #DAY_OF_WEEK, WEEK_OF_YEAR, WEEK_OF_MONTH, , #DAY_OF_WEEK_IN_MONTH#DOW_LOCALsão #YEAR_WOY todos computados de forma consistente na classe base, com base no #EXTENDED_YEAR, #DAY_OF_YEAR, #MONTHe #DAY_OF_MONTH, que são computados pela subclasse.</li>

</ul>

<intervalo com suporte>< do Big>B</b></big>

O intervalo permitido de Calendar foi restringido. GregorianCalendar usado para tentar dar suporte ao intervalo de datas com valores de milissegundos de Long.MIN_VALUE até Long.MAX_VALUE. Isso introduziu construções embaraçosas (hacks) que desaceleraram o desempenho. Ele também introduziu um comportamento não uniforme nos limites. O novo Calendar protocolo especifica o intervalo máximo de datas compatíveis como aquelas com números de dia juliano de -0x7F000000 .+0x7F000000 Isso corresponde a anos de ~5.800.000 BCE a ~5.800.000 CE. Os programadores devem usar as constantes protegidas Calendar para especificar uma data extremamente precoce ou extremamente tardia.

<Notas gerais>< do big>b</b></big>

<ul>

<as implementações do li>Calendars são <em>proleptic</em>. Por exemplo, embora o calendário gregoriano não tenha sido instituído até o século XVI, a GregorianCalendar classe dá suporte a datas antes do início histórico do calendário estendendo o sistema de calendário para trás no tempo. Da mesma forma, o HebrewCalendar se estende para trás antes do início de sua época em anos zero e negativos. As subclasses não geram exceções porque uma data precede o início histórico de um sistema de calendário. Em vez disso, eles implementam #handleGetLimit para retornar limites apropriados em #YEARcampos etc #ERA. Em seguida, se o calendário estiver definido como não ser brando, os valores de campo fora do intervalo dispararão uma exceção.</li>

<as subclasses do sistema li>Calendar calculam<um >ano</em> estendido. Isso difere do #YEAR campo em que ele varia em todos os valores inteiros, incluindo valores zero e negativos, e encapsula as informações do #YEAR campo e de todos os campos maiores. Assim, para o calendário gregoriano, ele #EXTENDED_YEAR é computado como ERA==AD ? YEAR : 1-YEAR. Outro exemplo é a contagem longa maia, que tem anos (KUN) e ciclos aninhados de anos (KATUN e BAKTUN). O Maia #EXTENDED_YEAR é computado como TUN + 20 * (KATUN + 20 * BAKTUN). A Calendar classe base usa o #EXTENDED_YEAR campo para calcular os campos relacionados à semana.</li>

</ul>

Java documentação para android.icu.util.Calendar.

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Project Open Source do Open Source e usadas de acordo com os termos descritos na Creative Commons 2.5.