IChronoLocalDate Interface

Definição

[Android.Runtime.Register("java/time/chrono/ChronoLocalDate", "", "Java.Time.Chrono.IChronoLocalDateInvoker", ApiSince=26)]
public interface IChronoLocalDate : IDisposable, Java.Interop.IJavaPeerable, Java.Lang.IComparable, Java.Time.Temporal.ITemporal, Java.Time.Temporal.ITemporalAdjuster

[<Android.Runtime.Register("java/time/chrono/ChronoLocalDate", "", "Java.Time.Chrono.IChronoLocalDateInvoker", ApiSince=26)>]
type IChronoLocalDate = interface
    interface IComparable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ITemporal
    interface ITemporalAccessor
    interface ITemporalAdjuster

Derivado

Java.Time.LocalDate

Atributos

RegisterAttribute

Implementações

IJavaObject IJavaPeerable IComparable ITemporal ITemporalAccessor ITemporalAdjuster IDisposable

Comentários

Uma data sem fuso horário de dia ou fuso horário em uma cronologia arbitrária, destinada a casos avançados de uso de globalização.

<b>A maioria dos aplicativos deve declarar assinaturas de método, campos e variáveis como LocalDate, não esta interface.</b>

A ChronoLocalDate é a representação abstrata de uma data em que o Chronology chronologysistema , ou calendário, é pluggável. A data é definida em termos de campos expressos por TemporalField, em que a maioria das implementações comuns são definidas em ChronoField. A cronologia define como o sistema de calendário opera e o significado dos campos padrão.

<h2>Quando usar essa interface</h2> O design da API incentiva o uso em vez dessa interface, mesmo no caso em que o aplicativo precisa lidar com vários sistemas de LocalDate calendário.

Esse conceito pode parecer surpreendente no início, pois a maneira natural de globalizar um aplicativo pode inicialmente parecer ser abstrair o sistema de calendário. No entanto, conforme explorado abaixo, abstrair o sistema de calendário geralmente é a abordagem errada, resultando em erros lógicos e difíceis de encontrar bugs. Dessa forma, deve ser considerada uma decisão arquitetônica em todo o aplicativo optar por usar essa interface em vez LocalDatede .

<h3>Problemas de arquitetura a serem considerados</h3> Esses são alguns dos pontos que devem ser considerados antes de usar essa interface em um aplicativo.

1) Os aplicativos que usam essa interface, em vez de usar apenas LocalDate, enfrentam uma probabilidade significativamente maior de bugs. Isso ocorre porque o sistema de calendário em uso não é conhecido no momento do desenvolvimento. Uma das principais causas de bugs é onde o desenvolvedor aplica suposições de seu conhecimento diário do sistema de calendário ISO ao código que se destina a lidar com qualquer sistema de calendário arbitrário. A seção a seguir descreve como essas suposições podem causar problemas O mecanismo principal para reduzir esse risco aumentado de bugs é um processo de revisão de código forte. Isso também deve ser considerado um custo extra na manutenção para o tempo de vida do código.

2) Essa interface não impõe a imutabilidade de implementações. Embora as notas de implementação indiquem que todas as implementações devem ser imutáveis, não há nada no sistema de código ou tipo para impor isso. Qualquer método declarado para aceitar um ChronoLocalDate poderia, portanto, ser aprovado em uma implementação mutável mal escrita mal ou mal-intencionada.

3) Os aplicativos que usam essa interface devem considerar o impacto das eras. LocalDate protege os usuários do conceito de eras, garantindo que getYear() retorne o ano proléptico. Essa decisão garante que os desenvolvedores possam pensar LocalDate em instâncias como compostas por três campos - ano, mês do ano e dia do mês. Por outro lado, os usuários dessa interface devem pensar em datas como consistindo em quatro campos - era, ano de era, mês do ano e dia do mês. O campo de era extra é frequentemente esquecido, mas é de vital importância para datas em um sistema de calendário arbitrário. Por exemplo, no sistema de calendário japonês, a era representa o reinado de um imperador. Sempre que um reinado termina e outro começa, o ano da era é redefinido para um.

4) O único padrão internacional acordado para passar uma data entre dois sistemas é o padrão ISO-8601 que exige o sistema de calendário ISO. Usar essa interface em todo o aplicativo inevitavelmente levará ao requisito de passar a data por um limite de rede ou componente, exigindo um formato ou protocolo específico do aplicativo.

5) A persistência de longo prazo, como um banco de dados, quase sempre aceitará apenas datas no sistema de calendário ISO-8601 (ou no Julian-Gregorianrelacionado). Passar datas em outros sistemas de calendário aumenta as complicações de interagir com a persistência.

6) Na maioria das vezes, a passagem de um ChronoLocalDate aplicativo é desnecessária, conforme discutido na última seção abaixo.

<h3>Suposições falsas que causam bugs no código< do sistema de vários calendários/h3> Conforme indicado acima, há muitos problemas a serem considerados ao tentar usar e manipular uma data em um sistema de calendário arbitrário. Esses são alguns dos principais problemas.

O código que consulta o dia do mês e pressupõe que o valor nunca será maior que 31 é inválido. Alguns sistemas de calendário têm mais de 31 dias em alguns meses.

Código que adiciona 12 meses a uma data e pressupõe que um ano foi adicionado é inválido. Alguns sistemas de calendário têm um número diferente de meses, como 13 no Copta ou Etépico.

O código que adiciona um mês a uma data e pressupõe que o valor de mês do ano aumentará em um ou encapsular para o próximo ano é inválido. Alguns sistemas de calendário têm um número variável de meses em um ano, como o hebraico.

O código que adiciona um mês, adiciona um segundo mês e pressupõe que o dia do mês permanecerá próximo ao seu valor original é inválido. Alguns sistemas de calendário têm uma grande diferença entre o comprimento do mês mais longo e o comprimento do mês mais curto. Por exemplo, o Copta ou Ethiopic tem 12 meses de 30 dias e 1 mês de 5 dias.

Código que adiciona sete dias e pressupõe que uma semana foi adicionada é inválido. Alguns sistemas de calendário têm semanas diferentes de sete dias, como o revolucionário francês.

Código que pressupõe que, como o ano é date1 maior do que o ano de date2 depois date1 , é date2 inválido. Isso é inválido para todos os sistemas de calendário ao se referir ao ano da era, e especialmente não confiável do sistema de calendário japonês onde o ano da era reinicia com o reinado de cada novo Imperador.

O código que trata o mês do ano um e o dia do mês um como o início do ano é inválido. Nem todos os sistemas de calendário começam o ano quando o valor do mês é um.

Em geral, manipular uma data e até mesmo consultar uma data é aberto a bugs quando o sistema de calendário é desconhecido no momento do desenvolvimento. É por isso que é essencial que o código que usa essa interface seja submetido a revisões de código adicionais. Também é por isso que uma decisão de arquitetura para evitar esse tipo de interface geralmente é a correta.

<h3>Usando LocalDate em vez disso</h3> A principal alternativa para usar essa interface em todo o aplicativo é a seguinte. <ul><li>Declarar todas as assinaturas de método referentes a datas em termos de LocalDate. <li>Armazene a cronologia (sistema de calendário) no perfil do usuário ou pesquise <a cronologia da localidade do usuário li>Converter o ISO LocalDate de e para o sistema de calendário preferencial do usuário durante a impressão e análise </ul> Essa abordagem trata o problema dos sistemas de calendário globalizados como um problema de localização e o limita à camada da interface do usuário. Essa abordagem está de acordo com outros problemas de localização na plataforma java.

Conforme discutido acima, a execução de cálculos em uma data em que as regras do sistema de calendário são pluggáveis requer habilidade e não é recomendada. Felizmente, a necessidade de executar cálculos em uma data em um sistema de calendário arbitrário é extremamente rara. Por exemplo, é altamente improvável que as regras de negócios de um esquema de aluguel de livros de bibliotecas permitam que os aluguéis sejam por um mês, em que o significado do mês depende do sistema de calendário preferencial do usuário.

Um caso de uso importante para cálculos em uma data em um sistema de calendário arbitrário está produzindo um calendário mês a mês para exibição e interação do usuário. Novamente, esse é um problema de interface do usuário e o uso dessa interface somente em alguns métodos da camada de interface do usuário pode ser justificado.

Em qualquer outra parte do sistema, em que uma data deve ser manipulada em um sistema de calendário diferente do ISO, o caso de uso geralmente especificará o sistema de calendário a ser usado. Por exemplo, um aplicativo pode precisar calcular o próximo feriado islâmico ou hebraico, o que pode exigir a manipulação da data. Esse tipo de caso de uso pode ser tratado da seguinte maneira: <ul><li>start from the ISO LocalDate being passed to the method <li>convert the date to the alternate calendar system, which for this use case is known in than arbitrary <li perform the calculation <li>>convert back to LocalDate</ul> Developers writing low-level frameworks or libraryes should also avoid this interface. Em vez disso, uma das duas interfaces de acesso de uso geral deve ser usada. Use TemporalAccessor se o acesso somente leitura for necessário ou se Temporal o acesso de leitura/gravação for necessário.

Adicionado em 1.8.

Java documentação para java.time.chrono.ChronoLocalDate.

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.