Je joue avec la nouvelle API de date et, juste par curiosité, je l'ai essayé d'exécuter le code suivant:Nouvelle API Date - Ajouter Era
LocalDateTime timePoint = LocalDateTime.now(ZoneId.of("Australia/Canberra"));
System.err.println(timePoint.plus(1, ChronoUnit.ERAS));
et a obtenu l'erreur suivante:
Exception in thread "main" java.time.DateTimeException: Invalid value for Era (valid values 0 - 1): 2
at java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
at java.time.temporal.ChronoField.checkValidValue(ChronoField.java:703)
at java.time.LocalDate.with(LocalDate.java:1023)
at java.time.LocalDate.plus(LocalDate.java:1245)
at java.time.LocalDateTime.plus(LocalDateTime.java:1194)
at pt.sibs.epms.Tester.method6(Tester.java:79)
at pt.sibs.epms.Tester.main(Tester.java:59)
Est-ce un bug ou je ne l'utilise pas correctement?
Qu'espériez-vous qu'il se passerait et pourquoi pensez-vous que le comportement réel serait un bug? Cela fonctionne selon [la documentation] (http://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#plus-long-java.time.temporal.TemporalUnit-) qui dit : "déclenche DateTimeException si l'ajout ne peut pas être effectué". Le calendrier standard (ISO) n'a que deux ères (BCE = avant l'ère commune et CE = ère commune). Il n'y a pas d'ère après l'ère actuelle (CE). – Jesper
Honnêtement, je ne m'attendais à rien, j'essayais juste l'API. J'étais surtout intrigué par le message d'erreur: "Valeur invalide pour Era (valeurs valides 0 - 1): 2", il semble étrange. Si vous essayez FOREVER au lieu de ERAS, vous obtenez "Unsupported unit", ce qui est logique. –
Je dirais que cet exemple prouve qu'il est complètement absurde d'utiliser des ères comme unités de temps - à l'exception du calendrier japonais. Les unités spécifiques au calendrier auraient été bien meilleures en tant que choix de conception. Jespers répondre à la raison concrète est juste (après l'ère grégorienne actuelle il n'y a pas l'ère suivante) .. –