Java dispose enfin d'un moyen intuitif et fiable de travailler avec les dates et les heures. Les principes de date et d’heure sont fondamentaux dans de nombreuses applications. Divers éléments tels que les dates de naissance, les dates de location, les heures d'événements et les heures d'ouverture des magasins sont tous basés sur des dates et des heures, mais Java SE ne fournissait pas un moyen pratique de travailler avec eux. À partir de Java SE 8 , il existait un ensemble de packages java.time , qui fournissent une API bien structurée pour travailler avec les dates et les heures.
Arrière-plan
Lorsque Java est sorti pour la première fois, dans la version 1.0 , la seule classe permettant de travailler avec les dates et les heures était java.util.Date . La première chose que les développeurs ont remarquée, c'est qu'il ne s'agit pas d'une « date ». En fait, il représente un instant précis, à la milliseconde près, mesuré à partir de la date du 1er janvier 1970. Cependant, étant donné que la méthode toString() de Date affiche la date et l'heure dans le fuseau horaire spécifié dans les paramètres Java de la machine , certains développeurs ont conclu à tort que Date pouvait fonctionner avec des fuseaux horaires. Corriger cette classe s'est avéré si difficile (ou si paresseux) que dans la version 1.1 , nous avons dû ajouter une nouvelle classe - java.util.Calendar . Malheureusement, la classe Calendar s'est avérée guère meilleure que Date .
Voici une petite liste des problèmes existants dans sa mise en œuvre :
Changeable. Les classes telles que la date et l’heure doivent être immuables.
Compensations. Les années dans Date commencent à 1900, les mois dans les deux classes commencent à zéro.
Des noms. La date n'est pas réellement une "date" et le calendrier n'est pas un calendrier.
Mise en page. Le formatage ne fonctionne qu'avec la date, pas avec le calendrier, et n'est pas thread-safe.
En 2001, le projet
Joda-Time est créé . Son objectif était simple : créer une bibliothèque de haute qualité pour travailler avec les dates et les heures en
Java .
Cela a pris du temps, mais la version 1.0 a finalement été publiée et est rapidement devenue très populaire et largement utilisée. Au fil du temps, les développeurs ont de plus en plus exigé qu'une bibliothèque aussi pratique soit fournie dans le cadre du
JDK .
Avec la participation de Michael Nascimento Santos du Brésil, le projet JSR-310 a été lancé , qui est le processus officiel de création et d'intégration d'une nouvelle
API pour travailler avec les dates et les heures dans
le JDK .
Revoir
La nouvelle
API java.time contient 5 packages :
java.time - le package de base contenant des objets pour stocker les valeurs
java.time.chrono - donne accès à différents calendriers
java.time.format - formatage et reconnaissance de la date et de l'heure
java.time.temporal - bibliothèques de bas niveau et fonctionnalités avancées
java.time.zone - cours pour travailler avec les fuseaux horaires
La plupart des développeurs utiliseront principalement le package de base et le formatage, et peut-être
java.time.temporal . Ainsi, même si 68 nouveaux types ont été ajoutés, les développeurs n’en utiliseront qu’un tiers environ.
Rendez-vous
La classe
LocalDate est l'une des plus importantes de la nouvelle
API . Il contient une valeur immuable qui représente une date. Vous ne pouvez pas régler l'heure ou le fuseau horaire. Le nom « local » vous est peut-être familier depuis
Joda-Time et provient à l'origine de la norme
ISO-8601 . Cela signifie précisément l’absence de fuseau horaire. Essentiellement,
LocalDate est une description d'une date, telle que « 5 avril 2014 ». L'heure réelle de cette date différera en fonction de votre fuseau horaire. Par exemple, en Australie, cette date sera 10 heures plus tôt qu'à Londres et 18 heures plus tôt qu'à San Francisco. La classe
LocalDate possède toutes les méthodes couramment nécessaires :
LocalDate date = LocalDate.of(2014, Month.JUNE, 10); int year = date.getYear(); // 2014 Month month = date.getMonth(); // Июнь int dom = date.getDayOfMonth(); // 10 DayOfWeek dow = date.getDayOfWeek(); // Вторник int len = date.lengthOfMonth(); // 30 (дней в Июне) boolean leap = date.isLeapYear(); // false (не високосный год) Dans notre exemple, nous voyons une date créée à l'aide d'une méthode d'usine (tous les constructeurs sont privés). Ensuite, nous demandons à l'objet certaines données. Veuillez noter que
les énumérations Month et
DayOfWeek sont conçues pour rendre le code plus lisible et plus fiable. Dans l'exemple suivant nous verrons comment modifier la date. Puisque la classe est immuable, le résultat sera de nouveaux objets, mais l'original restera tel qu'il était.
LocalDate date = LocalDate.of(2014, Month.JUNE, 10); date = date.withYear(2015); // 2015-06-10 date = date.plusMonths(2); // 2015-08-10 date = date.minusDays(1); // 2015-08-09 Ce sont des changements relativement simples, mais vous devez souvent effectuer des modifications de date plus complexes. Il existe un mécanisme spécial pour cela dans
l'API java.time - TemporalAdjuster . Son but est de fournir un outil intégré qui permet de manipuler les dates, par exemple en obtenant un objet correspondant au dernier jour du mois. Certains d'entre eux sont inclus dans
l'API , mais vous pouvez ajouter les vôtres. L'utilisation de modificateurs est très simple, mais cela nécessite des importations statiques :
import static java.time.DayOfWeek.* import static java.time.temporal.TemporalAdjusters.* LocalDate date = LocalDate.of(2014, Month.JUNE, 10); date = date.with(lastDayOfMonth()); date = date.with(nextOrSame(WEDNESDAY)); l'utilisation de modificateurs simplifie grandement votre code. Personne ne veut voir beaucoup de manipulations manuelles de la date. Si une sorte de manipulation de date se produit plusieurs fois dans votre projet, écrivez votre propre modificateur et votre équipe pourra l'utiliser comme composant déjà écrit et testé.
Heure et date comme valeurs
Cela vaut la peine de passer un peu de temps à comprendre ce qui fait de
LocalDate une valeur. Les valeurs sont des types de données simples et complètement interchangeables ; lorsqu'elles sont égales, l'identité des objets n'a plus de sens. Un exemple classique de classe de valeurs est
String . Nous comparons les chaînes en utilisant
equals() , et nous ne nous soucions pas de savoir si les objets sont identiques par rapport à l' opérateur
== . La plupart des classes permettant de travailler avec des dates et des heures sont également des valeurs. Ainsi, les comparer à l’aide de l’ opérateur
== est une mauvaise idée, comme indiqué dans la documentation. Pour ceux qui souhaitent en savoir plus, consultez ma récente définition
de VALJOs , qui décrit un ensemble strict de règles que les objets de valeur en
Java doivent suivre , y compris l'immuabilité, les méthodes d'usine et la définition appropriée de
equals() ,
hashCode ,
toString() , et
compareTo.() .
Calendriers alternatifs
La classe
LocalDate , comme toutes les classes principales de
java.time , est liée à un seul calendrier, comme décrit dans la norme
ISO-8601 . La norme 8601 décrit le calendrier standard mondial, également connu sous le nom de calendrier grégorien. Une année standard comprend 365 jours, une année bissextile - 366. Chaque quatrième année est une année bissextile à moins qu'elle ne soit divisible par 100 ou divisible par 400. L'année précédant la première année d'une nouvelle ère est considérée comme nulle pour faciliter le calcul. La première conséquence du fait qu'il s'agit d'un système par défaut est que les résultats ne correspondent pas toujours à ceux calculés à l'aide de
GregorianCalendar . La classe
GregorianCalendar possède un commutateur intégré vers le système julien pour toutes les dates antérieures au 15 octobre 1582. Dans le système julien, une année sur quatre était bissextile, sans exception. La question est, puisque le passage d'un système à un autre est un fait historique, pourquoi
java.time ne le modélise-t-il pas ? Oui, car différents pays sont passés au système grégorien à des moments différents, et en considérant uniquement la date de la transition du Vatican, nous obtiendrons des données incorrectes pour la plupart des autres pays. Par exemple, l’Empire britannique, y compris les colonies d’Amérique du Nord, est passé au calendrier grégorien le 14 septembre 1752, près de 200 ans plus tard. La Russie n’a modifié son calendrier que le 14 février 1918, et la transition de la Suède est généralement une question trouble. En conséquence, la signification réelle des dates antérieures à 1918 varie considérablement selon les circonstances. Les auteurs du code
LocalDate ont pris la décision tout à fait rationnelle de ne pas modéliser du tout le passage du calendrier julien au calendrier grégorien, afin d'éviter les divergences. La deuxième conséquence de l'utilisation
d'ISO-8601 comme calendrier par défaut dans toutes les classes principales est qu'un ensemble supplémentaire de classes est requis pour gérer les calendriers restants. L' interface
Chronologie constitue la base pour travailler avec des calendriers alternatifs, vous permettant de trouver le calendrier souhaité par nom de paramètres régionaux.
Java 8 est livré avec 4 calendriers supplémentaires : bouddhiste thaïlandais, Mingguo (taïwanais), japonais et islamique. D'autres calendriers peuvent être accompagnés de programmes. Chaque calendrier a une classe de date spéciale telle que
ThaiBuddhistDate ,
MinguoDate ,
JapaneseDate et
HijrahDate . Il est logique de les utiliser dans des applications très localisées, comme celles du gouvernement japonais. Une interface supplémentaire,
ChronoLocalDate , est utilisée comme abstraction de base des quatre classes ci-dessus avec
LocalDate, qui vous permet d'écrire du code indépendamment du type de calendrier utilisé. Bien que cette abstraction existe, son utilisation n’est pas recommandée. Comprendre pourquoi cette abstraction n'est pas recommandée est important pour comprendre le fonctionnement de l'ensemble de
l'API java.time . L’essentiel est que la plupart du code écrit sans référence à un calendrier spécifique s’avère ne pas fonctionner. Par exemple, vous ne pouvez pas être sûr qu'il y a 12 mois dans une année, mais certains développeurs ajoutent 12 mois et pensent avoir ajouté une année entière. Vous ne pouvez pas être sûr que tous les mois contiennent à peu près le même nombre de jours : dans le calendrier copte, il y a 12 mois de 30 jours et 1 mois de cinq ou six jours. De plus, vous ne pouvez pas être sûr que le nombre de l'année prochaine sera 1 de plus que celui en cours, car dans le calendrier japonais, les années sont comptées à partir de la proclamation du prochain empereur (dans ce cas, même 2 jours du même mois peut appartenir à des années différentes). La seule façon d'écrire du code fonctionnel et de haute qualité qui fonctionne avec plusieurs calendriers à la fois est que le cœur de votre code, qui effectue toutes les opérations sur les dates et les heures, doit être écrit à l'aide d'un calendrier standard, et uniquement lors de la saisie/sortie de dates. devrait-il être converti vers d’autres systèmes de calendrier. Autrement dit, il est recommandé d'utiliser
LocalDate pour le stockage et toutes les manipulations de dates dans votre application. Et ce n'est que lors de la localisation des dates d'entrée et de sortie que vous devez utiliser
ChronoLocalDate , qui est généralement obtenu à partir de la classe de calendrier stockée dans le profil utilisateur. Certes, la plupart des applications n'ont pas besoin d'une localisation aussi sérieuse. Si vous avez besoin d'une explication plus détaillée de tout ce qui est décrit dans ce chapitre, bienvenue dans la
documentation de la classe
ChronoLocalDate .
Suite de l'article Article original
GO TO FULL VERSION