Pourquoi manque-t-il une méthode getMillis () dans les classes java.time de Java 8?

Java 8 a une toute nouvelle bibliothèque pour les dates et les heures dans le paquet java.time, ce qui est très appréciable pour tous ceux qui ont déjà utilisé JodaTime ou qui ont du mal à créer leurs propres méthodes d’aide au traitement des dates. Beaucoup de classes de ce paquet représentent des horodatages et ont des méthodes d'assistance comme getHour()obtenir des heures d'horodatage, des getMinute()minutes d'horodatage, des getNano()nanos d'empreintes digitales, etc.

J'ai remarqué qu'ils ne disposent pas d'une méthode appelée getMillis()pour obtenir les millis de l'horodatage. Au lieu de cela, il faudrait appeler une 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 fait défaut ou que Java 8 est en cours de développement, y a-t-il une possibilité qu'il soit ajouté 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 calendrier mondial de facto qui suit les règles proleptiques grégoriennes. Toutes les classes sont immuables et thread-safe.

Chaque instance d’heure de date est composée de champs facilement mis à disposition par les API. Pour un accès de niveau inférieur aux champs, reportez-vous au java.time.temporalpackage. Chaque classe prend en charge l’impression et l’analyse de toutes sortes de dates et d’heures. Reportez-vous au java.time.formatpackage 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, telle que 2007-12-03T10: 15: 30.

LocalDateTimeest un objet date-heure immuable qui représente une date-heure, souvent considérée comme année-mois-jour-heure-minute-seconde. Vous pouvez également accéder à d'autres champs de date et d'heure, tels que le jour de l'année, le jour de la semaine et la semaine de l'année. Le temps est représenté à la précision nanoseconde. Par exemple, la valeur "2 octobre 2007 à 13h45: 30.30.123456789" peut être enregistrée dans un fichier LocalDateTime...

JSR-310 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 de disposer d'une base en nanosecondes était l'une des décisions initiales du projet, et une décision que je crois fermement être la bonne.

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

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

Avant de faire partie d’openJDK, Threeten était sur github et auparavant sur sourceforge. À l’époque, Stephen Colebourne, responsable des spécifications pour 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 4 et parmi eux environ 15% ont demandé un getMillis(), c'est-à-dire moins de 1% du total des voix.

C’est probablement pour cette raison qu’il n’y avait pas d’origine getMilliset que je ne trouvais rien de ce qui se rapportait à la liste de diffusion openjdk, la question n’a donc apparemment pas été abordée par la suite.

Les classes représentant des heures UTC non ambiguës (Instant, OffsetDateTime, ZoneDateTime) ont deux méthodes d'assistance pour accéder au décalage absolu à partir de l'époque Java, c'est-à-dire ce que vous appelez 'millisecond time' dans java.util.Date, que vous pouvez utiliser. atteindre en millisecondes

long getEpochSecond()
int getNano()

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

Certaines des raisons pour lesquelles ceci a été choisi à la place de long getEpochMillis()ont été discutées sur la liste de diffusion jsr 310 , dont certaines que j'ai extraites pour des raisons de commodité:

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

...

Pour implémenter ceci, mon option préférée serait une seconde longue de 64 bits (signée) + 32 bits en nanosecondes (non signé).

...

Je préfère que la scission se situe au deuxième niveau car il s’agit de l’unité de temps officielle du SI en sciences et de la norme la plus universellement acceptée.

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

La division à la seconde, comme proposé, donne une plage d’instants de nanosecondes sur 290 milliards d’années. Bien que personne ne devrait jamais utiliser cette précision sur cette plage temporelle, je dirais qu'il est plus facile de la prendre en charge que de la bloquer. Le découpage 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 essaient de comprendre les différences entre les différentes options et de ne pas utiliser (aveuglément) les nouvelles classes à l'aveuglette.

Pourquoi la LocalDateTimeclasse ne dispose-t-elle pas de ces méthodes? Elles ne peuvent probablement pas exister là-bas car elles LocalDateTimene sont pas liées à la chronologie UTC tant que vous n'avez pas décidé de la zone dans laquelle vous vous situez ou de votre décalage UTC. OffsetDateTimeou ZonedDateTime(qui ont tous deux les méthodes nécessaires).

Alternativement, vous pouvez définir votre propre LOCAL_EPOCHconstante à 1970-01-01T00:00:00puis faire un MILLIS.between(LOCAL_EPOCH, localTime)pour obtenir une sorte de durée en millisecondes. Toutefois, cette valeur 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 également utiliser Instant directement ou OffsetDateTime avec ZoneOffset.UTC.