web-dev-qa-db-fra.com

Pourquoi les classes Java 8 Java.time manquent-elles une méthode getMillis ()?

Java 8 a une toute nouvelle bibliothèque de dates et d'heures dans le package Java.time, ce qui est très bienvenu pour quiconque a déjà dû utiliser JodaTime ou s'embarrasser de créer ses propres méthodes d'aide au traitement des dates. De nombreuses classes de ce package représentent des horodatages et ont des méthodes d'assistance comme getHour() pour obtenir des heures d'horodatage, getMinute() pour obtenir des minutes d'horodatage, getNano() pour obtenir des nanos d'horodatage etc...

J'ai remarqué qu'ils n'ont pas de méthode appelée getMillis() pour obtenir les millis de l'horodatage. Au lieu de cela, il faudrait appeler la méthode get(ChronoField.MILLI_OF_SECOND). Pour moi, cela ressemble à une incohérence dans la bibliothèque. Quelqu'un sait-il pourquoi une telle méthode est manquante, ou comme Java 8 est encore en développement, y a-t-il une possibilité qu'elle soit ajoutée plus tard?

https://docs.Oracle.com/javase/8/docs/api/Java/time/package-summary.html

Les classes définies ici représentent les principaux concepts date-heure, notamment les instants, les durées, les dates, les heures, les fuseaux horaires et les périodes. Ils sont basés sur le système de calendrier ISO, qui est le de facto calendrier mondial suivant les règles grégoriennes proleptiques. Toutes les classes sont immuables et thread-safe.

Chaque instance de date-heure est composée de champs qui sont facilement mis à disposition par les API. Pour un accès de niveau inférieur aux champs, reportez-vous au Java.time.temporal paquet. Chaque classe inclut la prise en charge de l'impression et de l'analyse de toutes sortes de dates et d'heures. Se référer au Java.time.format package pour les options de personnalisation ...

Exemple de ce type de classe:
https://docs.Oracle.com/javase/8/docs/api/Java/time/LocalDateTime.html

Une date-heure sans fuseau horaire dans le système de calendrier ISO-8601, comme 2007-12-03T10: 15: 30.

LocalDateTime est un objet date-heure immuable qui représente une date-heure, souvent vue comme année-mois-jour-heure-minute-seconde. D'autres champs de date et d'heure, tels que jour de l'année, jour de la semaine et semaine de l'année, sont également accessibles. Le temps est représenté avec une précision en nanosecondes. Par exemple, la valeur "2 octobre 2007 à 13: 45.30.123456789" peut être stockée dans un LocalDateTime...

javajava8
65
Tarmo

JSR-31 est basé sur des nanosecondes, pas des millisecondes. En tant que tel, l'ensemble minimal de méthodes sensibles est basé sur l'heure, les minutes, la seconde et la nanoseconde. La décision d'avoir une base nanoseconde a été l'une des décisions initiales du projet, et je crois fermement qu'elle est correcte.

L'ajout d'une méthode pour les millis chevaucherait celle de la nanoseconde est une manière non évidente. Les utilisateurs devraient se demander si le champ nano était par exemple nano-seconde ou nano-milli. L'ajout d'une méthode supplémentaire déroutante n'est pas souhaitable, la méthode a donc été omise. Comme indiqué, l'alternative get(MILLI_OF_SECOND) est disponible.

FWIW, je m'opposerais à l'ajout de la méthode getMillis() à l'avenir.

63
JodaStephen

Avant de faire partie de openJDK, threeten était sur github et avant cela sur sourceforge. À l'époque, Stephen Colebourne, qui est un responsable des spécifications sur jsr-310, a fait une enquête que vous pouvez toujours trouver sur le site sourceforge .

The fourth question on the survey covered the method names for LocalTime:
1) getHourOfDay(), getMinuteOfHour(), getSecondOfMinute(), getNanoOfSecond()
2) getHour(), getMinute(), getSecond(), getNanoOfSecond()
3) getHour(), getMinute(), getSecond(), getNano()
4) another idea

seuls 6,23% ont choisi la réponse n ° 4 et parmi eux environ 15% ont demandé une getMillis(), soit moins de 1% du total des votes.

C'est probablement la raison pour laquelle il n'y avait pas de getMillis en premier lieu et je n'ai rien trouvé de similaire sur la liste de diffusion openjdk donc la question n'a apparemment pas été discutée par la suite.

20
assylias

Les classes qui représentent des heures UTC non ambiguës (ce sont Instant, OffsetDateTime, ZonedDateTime) ont deux méthodes d'assistance pour accéder à l'offset absolu de Java Epoch, c'est-à-dire ce que vous appelez "millisecond time" dans Java .util.Date, que vous pourriez utiliser pour obtenir en millisecondes

long getEpochSecond()
int getNano()

1000L*getEpochSecond() + getNano() / 1000000L;

Certaines raisons pour lesquelles cela a été choisi au lieu de long getEpochMillis() ont été discutées sur la liste de diffusion jsr 31 , dont j'ai extrait certaines pour plus de commodité:

il semble raisonnable de supposer que la précision en millisecondes ne sera pas suffisante. Cependant, toute précision supérieure à la nanoseconde semble excessive

...

Afin de mettre en œuvre cela, mon option préférée serait 64 secondes longues (signé) + 32 bits int nanosecondes (non signé).

...

Je préfère que la répartition soit au deuxième niveau car il s'agit de l'unité officielle de temps SI en science et de la norme la plus universellement acceptée.

Le fractionnement au niveau des jours est problématique pour les instants car il ne gère pas les secondes intercalaires. Le fractionnement au niveau des millisecondes, tout en s'intégrant légèrement mieux avec le reste de Java, semble vraiment assez étrange. De plus, il perd dans la plage prise en charge.

Le fractionnement au second comme proposé, donne une gamme d'instants de nanosecondes sur 290 milliards d'années. Bien que personne ne devrait jamais utiliser cette précision sur cette plage de la chronologie, je suggérerais qu'il est plus facile de le soutenir que de le bloquer. Le fractionnement au niveau des jours est problématique pour les instants car il ne gère pas les secondes intercalaires

J'ai le sentiment qu'une autre raison était de rendre intentionnellement difficile la conversion de Java.util.Date en classes JSR310, en espérant que les développeurs essaieraient de comprendre les différences entre les différentes options et ne se contenteraient pas d'utiliser aveuglément (mal) les nouvelles classes.

Quant à savoir pourquoi la classe LocalDateTime n'a pas ces méthodes - elles ne peuvent pas exister là parce que LocalDateTime n'est pas liée à la chronologie UTC jusqu'à ce que vous décidiez dans quelle zone vous vous trouvez ou quoi votre décalage UTC est, à quel point vous avez vous-même un OffsetDateTime ou ZonedDateTime (qui ont tous deux les méthodes nécessaires).

Alternativement, vous pouvez définir votre propre constante LOCAL_Epoch Sur 1970-01-01T00:00:00, Puis faire une MILLIS.between(LOCAL_Epoch, localTime) pour obtenir une sorte de durée en millisecondes. Cette valeur, cependant, ne sera compatible avec aucune valeur renvoyée par System.currentTimeMilliseconds() ou Java.util.Date.getTime(), à moins bien sûr que vous définissiez votre heure locale comme étant l'heure UTC; mais dans ce cas, vous pouvez tout aussi bien utiliser Instant directement ou OffsetDateTime avec ZoneOffset.UTC.

16
mkadunc