IChronoLocalDate Interfaz

Definición

[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

Implementaciones

IJavaObject IJavaPeerable IComparable ITemporal ITemporalAccessor ITemporalAdjuster IDisposable

Comentarios

Una fecha sin hora del día o zona horaria en una cronología arbitraria, pensada para casos de uso avanzados de globalización.

<b>La mayoría de las aplicaciones deben declarar firmas de método, campos y variables como LocalDate, no esta interfaz.</b>

Es ChronoLocalDate la representación abstracta de una fecha en la que se puede conectar el Chronology chronologysistema de calendario o . La fecha se define en términos de campos expresados por TemporalField, donde las implementaciones más comunes se definen en ChronoField. La cronología define cómo funciona el sistema de calendario y el significado de los campos estándar.

<h2>Cuando se usa esta interfaz</h2> El diseño de la API fomenta el uso de en lugar de LocalDate esta interfaz, incluso en el caso de que la aplicación necesite tratar con varios sistemas de calendario.

Este concepto puede parecer sorprendente al principio, ya que la manera natural de globalizar una aplicación podría parecer inicialmente ser abstraer el sistema de calendario. Sin embargo, como se explora a continuación, abstraer el sistema de calendario suele ser el enfoque incorrecto, lo que da lugar a errores lógicos y difíciles de encontrar errores. Por lo tanto, debe considerarse una decisión arquitectónica de toda la aplicación para elegir usar esta interfaz en lugar de LocalDate.

<h3>Problemas arquitectónicos a tener en cuenta</h3> Estos son algunos de los puntos que se deben tener en cuenta antes de usar esta interfaz en toda una aplicación.

1) Las aplicaciones que usan esta interfaz, en lugar de usar simplemente LocalDate, se enfrentan a una probabilidad significativamente mayor de errores. Esto se debe a que el sistema de calendario en uso no se conoce en tiempo de desarrollo. Una causa clave de errores es donde el desarrollador aplica suposiciones de su conocimiento diario del sistema de calendario ISO al código que está pensado para tratar con cualquier sistema de calendario arbitrario. En la sección siguiente se describe cómo esas suposiciones pueden causar problemas El mecanismo principal para reducir este mayor riesgo de errores es un proceso de revisión de código seguro. Esto también debe considerarse un costo adicional en mantenimiento durante la vigencia del código.

2) Esta interfaz no exige la inmutabilidad de las implementaciones. Aunque las notas de implementación indican que todas las implementaciones deben ser inmutables, no hay nada en el código o sistema de tipos para aplicar esto. Por lo tanto, cualquier método declarado para aceptar podría ChronoLocalDate pasarse una implementación mutable mal escrita o malintencionadamente.

3) Las aplicaciones que usan esta interfaz deben tener en cuenta el impacto de las eras. LocalDate blinda a los usuarios del concepto de eras, asegurándose de que getYear() devuelve el año proléptico. Esa decisión garantiza que los desarrolladores piensen en LocalDate instancias que constan de tres campos: año, mes de año y día de mes. Por el contrario, los usuarios de esta interfaz deben pensar en fechas que constan de cuatro campos: era, año de era, mes de año y día de mes de mes. El campo de la era adicional se olvida con frecuencia, pero es de importancia vital para las fechas en un sistema de calendario arbitrario. Por ejemplo, en el sistema de calendario japonés, la era representa el reinado de un emperador. Cada vez que finaliza un reinado y otro comienza, el año de la era se restablece a uno.

4) El único estándar internacional acordado para pasar una fecha entre dos sistemas es la norma ISO-8601 que requiere el sistema de calendario ISO. El uso de esta interfaz en toda la aplicación provocará inevitablemente el requisito de pasar la fecha a través de un límite de red o componente, lo que requiere un protocolo o formato específicos de la aplicación.

5) La persistencia a largo plazo, como una base de datos, casi siempre solo aceptará fechas en el sistema de calendario ISO-8601 (o el Julian-Gregorianrelacionado). Pasar fechas en otros sistemas de calendario aumenta las complicaciones de interactuar con la persistencia.

6) La mayoría de las veces, pasar un elemento ChronoLocalDate a lo largo de una aplicación no es necesario, como se describe en la última sección siguiente.

<h3>Suposiciones falsas que provocan errores en el código< del sistema de varios calendarios/h3> Como se indicó anteriormente, hay muchos problemas que se deben tener en cuenta al intentar usar y manipular una fecha en un sistema de calendario arbitrario. Estos son algunos de los problemas clave.

Código que consulta el día del mes y supone que el valor nunca será mayor que 31 no es válido. Algunos sistemas de calendario tienen más de 31 días en algunos meses.

El código que agrega 12 meses a una fecha y supone que se ha agregado un año no es válido. Algunos sistemas de calendario tienen un número diferente de meses, como 13 en el Coptic o Ethiopic.

El código que agrega un mes a una fecha y supone que el valor de mes de año aumentará en uno o se ajustará al año siguiente no es válido. Algunos sistemas de calendario tienen un número variable de meses en un año, como el hebreo.

El código que agrega un mes y, a continuación, agrega un segundo mes y supone que el día del mes permanecerá cerca de su valor original no es válido. Algunos sistemas de calendario tienen una gran diferencia entre la longitud del mes más largo y la longitud del mes más corto. Por ejemplo, el Coptic o Ethiopic tienen 12 meses de 30 días y 1 mes de 5 días.

El código que agrega siete días y supone que se ha agregado una semana no es válido. Algunos sistemas de calendario tienen semanas de más de siete días, como el revolucionario francés.

Código que supone que, debido a que el año de date1 es mayor que el año de date2 , date1 después date2 , no es válido. Esto no es válido para todos los sistemas de calendario al referirse al año de la era, y especialmente al sistema de calendario japonés donde el año de la era se reinicia con el reinado de cada nuevo emperador.

El código que trata el mes de año uno y el día del mes uno como inicio del año no es válido. No todos los sistemas de calendario inician el año cuando el valor del mes es uno.

En general, manipular una fecha e incluso consultar una fecha está abierta a errores cuando el sistema de calendario es desconocido en tiempo de desarrollo. Por este motivo, es esencial que el código que usa esta interfaz esté sujeto a revisiones de código adicionales. También es por eso que una decisión arquitectónica para evitar este tipo de interfaz suele ser la correcta.

<h3>Usar LocalDate en su lugar</h3> La alternativa principal a usar esta interfaz en toda la aplicación es la siguiente. <ul><li>Declare todas las firmas de método que hacen referencia a fechas en términos de LocalDate. <li>Almacene la cronología (sistema de calendario) en el perfil de usuario o busque la cronología del usuario locale <li>Convert the ISO LocalDate to and from the user's preferred calendar system during printing and parsing </ul> Este enfoque trata el problema de los sistemas de calendario globalizados como un problema de localización y lo limita a la capa de interfaz de usuario. Este enfoque está en consonancia con otros problemas de localización en la plataforma java.

Como se explicó anteriormente, realizar cálculos en una fecha en la que las reglas del sistema de calendario son conectables requiere aptitud y no se recomienda. Afortunadamente, la necesidad de realizar cálculos en una fecha en un sistema de calendario arbitrario es extremadamente poco frecuente. Por ejemplo, es muy improbable que las reglas de negocios de un esquema de alquiler de libros de biblioteca permitan que los alquileres sean durante un mes, donde el significado del mes depende del sistema de calendario preferido del usuario.

Un caso de uso clave para los cálculos de una fecha en un sistema de calendario arbitrario genera un calendario mensual por mes para mostrar e interactuar con el usuario. De nuevo, se trata de un problema de interfaz de usuario y el uso de esta interfaz solo dentro de algunos métodos de la capa de interfaz de usuario puede justificarse.

En cualquier otra parte del sistema, donde se debe manipular una fecha en un sistema de calendario distinto de ISO, el caso de uso generalmente especificará el sistema de calendario que se va a usar. Por ejemplo, una aplicación puede necesitar calcular el siguiente día festivo islámico o hebreo que puede requerir manipular la fecha. Este tipo de caso de uso se puede controlar de la siguiente manera: <ul><li>start desde la ISO LocalDate que se pasa al método <li>convierte la fecha en el sistema de calendario alternativo, que para este caso de uso se conoce en lugar de realizar la conversión arbitraria <li>de<> cálculo a LocalDate</ul> Developers escribiendo marcos o bibliotecas de bajo nivel también debe evitar esta interfaz. En su lugar, se debe usar una de las dos interfaces de acceso de uso general. Use TemporalAccessor si se requiere acceso de solo lectura o use Temporal si se requiere acceso de lectura y escritura.

Agregado en la versión 1.8.

Java documentación para java.time.chrono.ChronoLocalDate.

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.