Alors passons à autre chose. L'entité suivante après la date est l'heure de la journée, représentée par la classe LocalTime . Un exemple classique est la représentation des heures d'ouverture d'un magasin, disons de 7h00 à 23h00. Les magasins ouvrent à cette heure dans tout le pays, mais les horaires réels varient en fonction du fuseau horaire. LocalTime est une classe de valeurs qui stocke uniquement l'heure, sans date ni fuseau horaire associé. Lors de l’ajout ou de la soustraction d’une période horaire, celle-ci sera coupée à minuit. Autrement dit, 20h00 plus 6 heures font 2h00. L'utilisation de LocalTime est similaire à LocalDate : LocalTime time = LocalTime.of(20, 30); int hour = date.getHour(); // 20 int minute = date.getMinute(); // 30 time = time.withSecond(6); // 20:30:06 time = time.plusMinutes(3); // 20:33:06 les modificateurs peuvent fonctionner avec LocalTime , mais les opérations temporelles ne sont généralement pas si complexes que des modificateurs soient nécessaires.
Combiner la date et l'heure
La prochaine classe que nous examinerons est
LocalDateTime . Cette classe de valeurs est une combinaison de
LocalDate et
LocalTime . Il représente à la fois la date et l'heure, sans fuseau horaire.
LocalDateTime peut être créé directement ou en combinant la date et l'heure :
LocalDateTime dt1 = LocalDateTime.of(2014, Month.JUNE, 10, 20, 30); LocalDateTime dt2 = LocalDateTime.of(date, time); LocalDateTime dt3 = date.atTime(20, 30); LocalDateTime dt4 = date.atTime(time); les troisième et quatrième options utilisent la méthode
atTime() , qui offre un moyen flexible de combiner la date et l'heure. La plupart des classes système de date et d'heure ont des méthodes "at" qui peuvent être utilisées lors de la combinaison de votre objet avec un autre pour en créer un plus complexe. Les autres méthodes de la classe
LocalDateTime sont similaires à celles de
LocalDate et
LocalTime . Des modèles de dénomination de méthodes similaires facilitent l'apprentissage
de l'API . Ce tableau répertorie tous les préfixes de méthode impliqués :
Instantané
Lorsque nous traitons de dates et d’heures, nous travaillons généralement avec des années, des mois, des jours, des heures, des minutes et des secondes. Cependant, il ne s’agit là que d’un modèle de temps que l’on peut qualifier de « humain ». Le deuxième modèle couramment utilisé est le temps « machine » ou « continu ». Dans ce modèle, un point sur l’axe du temps est représenté par un grand nombre. Cette approche simplifie les algorithmes de calcul et est utilisée pour stocker le temps dans le système d'exploitation
Unix , où le temps est représenté par le nombre de secondes écoulées depuis le 1er janvier 1970. De même, en
Java , le temps est stocké sous forme de nombre de millisecondes écoulées depuis le 1er janvier 1970. L'approche machine des calculs de temps dans
l'API java.time est fournie par la classe de valeur
instantanée . Il offre la possibilité de représenter un point sur un axe temporel sans toutes les informations qui l'accompagnent, telles que le fuseau horaire. En fait, cette classe contient le nombre de nanosecondes écoulées depuis le 1er janvier 1970 à minuit.
Instant start = Instant.now(); // произведем вычисления Instant end = Instant.now(); assert end.isAfter(start); //машина времени не сработала Généralement, la classe
Instant est utilisée pour stocker et comparer des moments dans le temps lorsque vous devez stocker le moment où un événement s'est produit, mais vous ne vous souciez pas du fuseau horaire dans lequel il s'est produit.
Dans la plupart des cas, ce que nous ne pouvons pas faire avec la classe Instant est plus intéressant que ce que nous pouvons faire avec elle. Par exemple, les lignes de code suivantes généreront des exceptions :
instant.get(ChronoField.MONTH_OF_YEAR); instant.plus(6, ChronoUnit.YEARS); Des exceptions se produisent car l' objet
instantané stocke uniquement le nombre de nanosecondes et n'offre pas la possibilité de travailler avec des unités de temps plus utiles aux humains. Pour utiliser d'autres unités de mesure, vous devez au moins spécifier un fuseau horaire.
Fuseaux horaires
Le principe des fuseaux horaires a été développé en Angleterre lorsque l'invention des chemins de fer et l'amélioration d'autres moyens de communication ont permis aux gens de parcourir des distances suffisantes pour que les différences d'heure solaire soient perceptibles. Jusqu'à cette époque, chaque village et chaque ville vivait selon son heure, qui était le plus souvent mesurée par un cadran solaire. Cette image montre un exemple des difficultés que cela a entraînées : les aiguilles rouges de l'horloge indiquent l'heure de Greenwich et les aiguilles noires indiquent l'heure locale, qui diffère de 10 minutes : le système de fuseaux horaires s'est développé, remplaçant l'heure solaire locale
. Mais le fait essentiel est que les fuseaux horaires sont créés par les politiciens et sont souvent utilisés pour démontrer le contrôle politique sur une région. Comme toute politique, les règles liées aux fuseaux horaires défient souvent la logique. Et aussi, ces règles peuvent changer, et changent souvent, sans aucun avertissement. Les règles de fuseau horaire sont compilées par un groupe international qui publie la base de données des fuseaux horaires
IANA . Il contient l'identifiant de chaque région de la Terre et l'historique des changements de fuseau horaire pour celle-ci. Les identifiants ressemblent à
« Europe/Londres » ou
« America/New_York » . Avant la sortie
de l'API java.time , la classe TimeZone était utilisée pour représenter un fuseau horaire .
Désormais, ZoneId est utilisé à la place . Il existe deux différences clés entre eux. Premièrement,
ZoneId est immuable, ce qui permet, entre autres, de stocker des objets de cette classe dans des variables statiques. Deuxièmement, les règles elles-mêmes sont stockées dans la classe
ZoneRules , et non dans le
ZoneId lui-même , et pour les obtenir, vous devez appeler la méthode
getRules() sur l' objet de classe
ZoneId . Une caractéristique commune à tous les fuseaux horaires est un décalage fixe par rapport à
UTC/Greenwich . Le plus souvent, vous l'utilisez pour parler du décalage horaire entre différentes villes, par exemple "New York a 5 heures de retard sur Londres". La classe
ZoneOffset , descendante de
ZoneId , représente le décalage horaire avec le méridien d'origine passant par Greenwich à Londres. Du point de vue d'un développeur, ce serait formidable de ne pas avoir à gérer les fuseaux horaires et leurs complexités.
L'API java.time vous permet de le faire aussi longtemps que cela est possible. Dans la mesure du possible, utilisez les classes
LocalDate, LocalTime, LocalDateTime et
Instant . Là où vous ne pouvez pas vous passer des fuseaux horaires, utilisez la classe
ZonedDateTime . Classe
ZonedDateTimevous permet de convertir les dates et les heures des unités de mesure humaines, que nous voyons sur les calendriers et les montres, en unités machine. En conséquence, vous pouvez créer
un ZonedTimeDate soit à partir de la classe
Local , soit à partir de la classe Instant :
ZoneId zone = ZoneId.of("Europe/Paris"); LocalDate date = LocalDate.of(2014, Month.JUNE, 10); ZonedDateTime zdt1 = date.atStartOfDay(zone); Instant instant = Instant.now(); ZonedDateTime zdt2 = instant.atZone(zone); L'une des caractéristiques les plus désagréables des fuseaux horaires est ce qu'on appelle l'heure d'été. Avec le passage à l'heure d'été vers et depuis Greenwich, votre décalage horaire avec Greenwich change deux fois (ou plus) par an, augmentant généralement au printemps et diminuant à l'automne. Lorsque cela se produit, nous devons changer toutes les horloges de notre maison. Dans les classes
java.time , les données de décalage sont représentées sous forme de
"transformations de décalage" . Au printemps, cela provoque un « décalage » dans le temps, lorsque certaines valeurs de temps sont impossibles, et à l'automne, au contraire, certaines valeurs de temps apparaissent deux fois. Tout cela est pris en charge par la classe
ZonedDateTime via ses méthodes d'usine et ses méthodes de conversion. Par exemple, l'ajout d'un jour ajoute un jour logique, qui peut être représenté par plus ou moins de 24 heures si l'on passe à l'heure d'été ou inversement.
De même, la méthode atStartOfDay() est nommée ainsi car nous ne pouvons pas garantir que la journée commencera exactement à minuit - nous devons prendre en compte le décalage horaire lors du passage à l'heure d'été. Et un dernier conseil concernant l’heure d’été. Si vous souhaitez démontrer que vous avez pris en compte le chevauchement temporel lors de la transition de l'été à l'hiver (lorsque la même valeur temporelle apparaît deux fois), vous pouvez utiliser l'une des deux méthodes spéciales conçues pour de telles situations : Ces méthodes renverront la date la plus précoce ou la plus tardive.
zdt = zdt.withEarlierOffsetAtOverlap(); zdt = zdt.withLaterOffsetAtOverlap(); valeur , si l'objet est pris dans un chevauchement lors du passage de l'heure d'été à l'heure d'hiver. Dans toutes les autres situations, les valeurs de retour seront les mêmes.
Intervalles de temps
Tous les cours dont nous avons discuté précédemment fonctionnent comme des points sur la chronologie. Deux classes de valeurs supplémentaires sont nécessaires pour représenter les intervalles de temps. La classe
Durée représente une durée, mesurée en secondes et en nanosecondes. Par exemple, « 23,6 secondes ». La classe
Period représente une période de temps mesurée en années, mois et jours. Par exemple : « 3 ans, 2 mois et 6 jours ». Ces intervalles peuvent être ajoutés ou soustraits à une date ou une heure :
Period sixMonths = Period.ofMonths(6); LocalDate date = LocalDate.now(); LocalDate future = date.plus(sixMonths);
Formatage et analyse
Un package entier est conçu pour formater et afficher les dates et les heures -
java.time.format . Le package s'articule autour de la classe
DateTimeFormatter et de sa fabrique
DateTimeFormatterBuilder . Les méthodes les plus courantes pour créer un formateur consistent à utiliser des méthodes statiques et des constantes dans
DateTimeFormatter , notamment :
Constantes pour les formats courants décrits dans ISO, tels que ISO_LOCAL_DATE.
Modèles identifiés par des lettres, tels que ofPattern("dd/MM/uuuu").
Styles localisés tels que ofLocalizedDate(FormatStyle.MEDIUM).
Une fois que vous avez créé un formateur, vous l'utilisez généralement en le transmettant à la méthode de classe de date appropriée :
DateTimeFormatter f = DateTimeFormatter.ofPattern("dd/MM/uuuu"); LocalDate date = LocalDate.parse("24/06/2014", f); String str = date.format(f); de cette façon, le code responsable du formatage de la sortie de date est isolé dans une classe distincte. Si vous devez spécifier séparément les paramètres régionaux pour le formatage de la date, utilisez la méthode de formatage
withLocale(Locale) . Les classes responsables du calendrier, du fuseau horaire et de l'entrée/sortie des nombres fractionnaires ont des méthodes similaires. Si vous avez besoin de plus d'options de réglage, consultez la documentation de la classe
DateTimeFormatterBuilder , qui vous permet de créer des formateurs complexes étape par étape. Il vous permet également de définir une analyse de texte insensible à la casse, d'ignorer certaines erreurs d'analyse, de définir des décalages et des éléments facultatifs.
Conclusion
L'API java.time est un nouveau modèle complet permettant de travailler avec la date et l'heure dans
Java SE 8 . Il fait passer les idées et les implémentations de
Joda-Time au niveau supérieur et permet enfin aux développeurs d'éviter d'utiliser
java.util.Date et
Calendar . Désormais, travailler avec des dates et des heures peut être amusant !
. Mais le fait essentiel est que les fuseaux horaires sont créés par les politiciens et sont souvent utilisés pour démontrer le contrôle politique sur une région. Comme toute politique, les règles liées aux fuseaux horaires défient souvent la logique. Et aussi, ces règles peuvent changer, et changent souvent, sans aucun avertissement. Les règles de fuseau horaire sont compilées par un groupe international qui publie la base de données des fuseaux horaires
IANA . Il contient l'identifiant de chaque région de la Terre et l'historique des changements de fuseau horaire pour celle-ci. Les identifiants ressemblent à
« Europe/Londres » ou
« America/New_York » . Avant la sortie
de l'API java.time , la classe
TimeZone était utilisée pour représenter un fuseau horaire .
Désormais, ZoneId est utilisé à la place . Il existe deux différences clés entre eux. Premièrement,
ZoneId est immuable, ce qui permet, entre autres, de stocker des objets de cette classe dans des variables statiques. Deuxièmement, les règles elles-mêmes sont stockées dans la classe
ZoneRules , et non dans le
ZoneId lui-même , et pour les obtenir, vous devez appeler la méthode
getRules() sur l' objet de classe
ZoneId . Une caractéristique commune à tous les fuseaux horaires est un décalage fixe par rapport à
UTC/Greenwich . Le plus souvent, vous l'utilisez pour parler du décalage horaire entre différentes villes, par exemple "New York a 5 heures de retard sur Londres". La classe
ZoneOffset , descendante de
ZoneId , représente le décalage horaire avec le méridien d'origine passant par Greenwich à Londres. Du point de vue d'un développeur, ce serait formidable de ne pas avoir à gérer les fuseaux horaires et leurs complexités.
L'API java.time vous permet de le faire aussi longtemps que cela est possible. Dans la mesure du possible, utilisez les classes
LocalDate, LocalTime, LocalDateTime et
Instant . Là où vous ne pouvez pas vous passer des fuseaux horaires, utilisez la classe
ZonedDateTime . Classe
ZonedDateTimevous permet de convertir les dates et les heures des unités de mesure humaines, que nous voyons sur les calendriers et les montres, en unités machine. En conséquence, vous pouvez créer
un ZonedTimeDate soit à partir de la classe
Local , soit à partir
de la classe Instant :
GO TO FULL VERSION