IChronoLocalDate Interface

Définition

[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

Dérivé

Java.Time.LocalDate

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable IComparable ITemporal ITemporalAccessor ITemporalAdjuster IDisposable

Remarques

Date sans fuseau horaire ou heure dans une chronologie arbitraire, destinée aux cas d’usage avancés de la mondialisation.

<b>La plupart des applications doivent déclarer des signatures de méthode, des champs et des variables comme LocalDate, et non cette interface.</b>

Il ChronoLocalDate s’agit de la représentation abstraite d’une date où le système de calendrier ou le Chronology chronologysystème de calendrier est enfichable. La date est définie en termes de champs exprimés par TemporalField, où les implémentations les plus courantes sont définies dans ChronoField. La chronologie définit le fonctionnement du système de calendrier et la signification des champs standard.

<h2>Quand utiliser cette interface</h2> La conception de l’API encourage l’utilisation plutôt LocalDate que cette interface, même si l’application doit traiter plusieurs systèmes de calendrier.

Ce concept peut sembler surprenant d’abord, car la façon naturelle de globaliser une application peut d’abord sembler abstraite du système de calendrier. Toutefois, comme indiqué ci-dessous, l’abstraction du système de calendrier est généralement la mauvaise approche, ce qui entraîne des erreurs logiques et des bogues difficiles à trouver. Par conséquent, il doit être considéré comme une décision architecturale à l’échelle de l’application de choisir d’utiliser cette interface par opposition à LocalDate.

<Problèmes architecturaux h3>à prendre en compte</h3> Voici quelques-uns des points qui doivent être pris en compte avant d’utiliser cette interface dans une application.

1) Les applications utilisant cette interface, plutôt que d’utiliser simplement LocalDate, font face à une probabilité considérablement plus élevée de bogues. Cela est dû au fait que le système de calendrier en cours d’utilisation n’est pas connu au moment du développement. Une cause clé des bogues est l’endroit où le développeur applique des hypothèses de sa connaissance quotidienne du système de calendrier ISO au code destiné à traiter n’importe quel système de calendrier arbitraire. La section ci-dessous décrit comment ces hypothèses peuvent entraîner des problèmes Le mécanisme principal permettant de réduire ce risque accru de bogues est un processus de révision de code fort. Cela doit également être considéré comme un coût supplémentaire en maintenance pour la durée de vie du code.

2) Cette interface n’applique pas l’immuabilité des implémentations. Bien que les notes d’implémentation indiquent que toutes les implémentations doivent être immuables, il n’y a rien dans le code ou le système de type pour l’appliquer. Toute méthode déclarée pour accepter un ChronoLocalDate peut donc être transmise à une implémentation mutable mal écrite ou malveillante.

3) Les applications utilisant cette interface doivent tenir compte de l’impact des ères. LocalDate protège les utilisateurs du concept d’ères, en garantissant qu’ils getYear() retournent l’année proleptique. Cette décision garantit que les développeurs peuvent considérer les LocalDate instances comme composées de trois champs : année, mois de l’année et jour du mois. En revanche, les utilisateurs de cette interface doivent considérer les dates comme composées de quatre champs : ère, année de l’ère, mois de l’année et jour du mois. Le champ d’ère supplémentaire est souvent oublié, mais il est essentiel de dater dans un système de calendrier arbitraire. Par exemple, dans le système de calendrier japonais, l’ère représente le règne d’un empereur. Chaque fois qu’un règne se termine et qu’un autre commence, l’année de l’ère est réinitialisée à une.

4) La seule norme internationale acceptée pour passer une date entre deux systèmes est la norme ISO-8601 qui requiert le système de calendrier ISO. L’utilisation de cette interface tout au long de l’application entraîne inévitablement la nécessité de passer la date à travers une limite de réseau ou de composant, nécessitant un protocole ou un format spécifique à l’application.

5) La persistance à long terme, telle qu’une base de données, n’acceptera presque toujours que les dates dans le système de calendrier ISO-8601 (ou les Julian-Gregorianassociées). Le passage de dates dans d’autres systèmes de calendrier augmente les complications liées à l’interaction avec la persistance.

6) La plupart du temps, le passage d’une ChronoLocalDate application n’est pas nécessaire, comme indiqué dans la dernière section ci-dessous.

<H3>Fausses hypothèses provoquant des bogues dans le code< système multi-calendrier/h3> Comme indiqué ci-dessus, il existe de nombreux problèmes à prendre en compte lors de la tentative d’utilisation et de manipulation d’une date dans un système de calendrier arbitraire. Voici quelques-unes des principales questions.

Code qui interroge le jour du mois et suppose que la valeur ne sera jamais supérieure à 31 n’est pas valide. Certains systèmes de calendrier ont plus de 31 jours en quelques mois.

Code qui ajoute 12 mois à une date et suppose qu’une année a été ajoutée n’est pas valide. Certains systèmes de calendrier ont un nombre différent de mois, tels que 13 dans le copte ou l’échiopice.

Le code qui ajoute un mois à une date et part du principe que la valeur mois de l’année augmente d’une ou d’une enveloppe à l’année suivante n’est pas valide. Certains systèmes de calendrier ont un nombre variable de mois en un an, comme l’hébreu.

Le code qui ajoute un mois, puis ajoute un deuxième mois et suppose que le jour du mois reste proche de sa valeur d’origine n’est pas valide. Certains systèmes de calendrier ont une grande différence entre la longueur du mois le plus long et la longueur du mois le plus court. Par exemple, le copte ou l’échiopice ont 12 mois de 30 jours et 1 mois de 5 jours.

Code qui ajoute sept jours et suppose qu’une semaine a été ajoutée n’est pas valide. Certains systèmes de calendrier ont des semaines d’autres que sept jours, comme le révolutionnaire français.

Code qui part du principe que, étant donné que l’année de date1 l’année est supérieure à l’année suivantedate2, elle n’est date2 pas date1 valide. Cela n’est pas valide pour tous les systèmes de calendrier lorsque vous faites référence à l’année de l’ère, et surtout à l’intrus du système de calendrier japonais où l’année de l’ère redémarre avec le règne de chaque nouvel empereur.

Code qui traite le mois de l’année un et le jour du mois comme le début de l’année n’est pas valide. Tous les systèmes de calendrier ne démarrent pas l’année lorsque la valeur du mois est une.

En général, la manipulation d’une date, et même l’interrogation d’une date, est largement ouverte aux bogues lorsque le système de calendrier est inconnu au moment du développement. C’est pourquoi il est essentiel que le code utilisant cette interface soit soumis à des révisions de code supplémentaires. C’est également pourquoi une décision architecturale d’éviter ce type d’interface est généralement la bonne.

<h3>Utilisation de LocalDate à la place</h3> L’alternative principale à l’utilisation de cette interface dans votre application est la suivante. <ul><li>Déclarez toutes les signatures de méthode faisant référence à des dates en termes de LocalDate. <li>stockez la chronologie (système de calendrier) dans le profil utilisateur ou recherchez la chronologie des paramètres régionaux <de l’utilisateur li>Convertir l’ISO LocalDate vers et à partir du système de calendrier préféré de l’utilisateur lors de l’impression et de l’analyse </ul> Cette approche traite le problème des systèmes de calendrier globalisés comme un problème de localisation et le limite à la couche d’interface utilisateur. Cette approche est conforme à d’autres problèmes de localisation dans la plateforme Java.

Comme indiqué ci-dessus, l’exécution de calculs à une date où les règles du système de calendrier sont enfichables nécessite une compétence et n’est pas recommandée. Heureusement, la nécessité d’effectuer des calculs sur une date dans un système de calendrier arbitraire est extrêmement rare. Par exemple, il est très peu probable que les règles d’entreprise d’un schéma de location de livres de bibliothèque autorisent les locations pendant un mois, où la signification du mois dépend du système de calendrier préféré de l’utilisateur.

Un cas d’usage clé pour les calculs sur une date dans un système de calendrier arbitraire produit un calendrier mensuel par mois pour l’affichage et l’interaction utilisateur. Là encore, il s’agit d’un problème d’interface utilisateur et l’utilisation de cette interface uniquement dans quelques méthodes de la couche d’interface utilisateur peut être justifiée.

Dans toute autre partie du système, où une date doit être manipulée dans un système de calendrier autre que ISO, le cas d’usage spécifie généralement le système de calendrier à utiliser. Par exemple, une application peut avoir besoin de calculer le prochain congé islamique ou hébreu qui peut nécessiter la manipulation de la date. Ce type de cas d’usage peut être géré comme suit : <ul><li start from the ISO LocalDate being passed to the method <li>>convert the date to the alternate calendar system, qui pour ce cas d’usage est connu plutôt que arbitraire <li>effectuer le calcul <li>convert to LocalDate</ul> Developers écrivant des frameworks ou bibliothèques de bas niveau doit également éviter cette interface. Au lieu de cela, l’une des deux interfaces d’accès à usage général doit être utilisée. Utilisez TemporalAccessor si l’accès en lecture seule est requis ou si Temporal l’accès en lecture-écriture est requis.

Ajouté dans la version 1.8.

Documentation Java pour java.time.chrono.ChronoLocalDate.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.