Quelqu'un peut-il penser à une utilisation pratique de XMLGregorianCalendar.getEon ()?

Question

Je suis tombé sur la classe XMLGregorianCalendar il y a quelque temps et j'ai été impressionné par la façon dont cela donnait à GregorianCalendar un aspect léger.;)

Récemment, j'ai remarqué une méthode BitInteger getEon() qui me déroute.

Depuis la Javadoc pour XMLGregorianCalendar

getYear () est une valeur comprise entre - (10 ^ 9-1) et (10 ^ 9) -1 ou DatatypeConstants.FIELD_UNDEFINED. getEon () est la valeur d'une année de haut niveau en milliards d'années.

Il me vient à l'esprit qu'à mesure que la durée du jour sur Terre change considérablement au cours des millions d'années et là, le nombre de jours dans une année a changé.Le calendrier grégorien n'aurait aucun sens il y a un milliard d'années ou un milliard d'années.Donc getEon () ne peut être raisonnablement défini que sur 0 ou laissé non défini, ce qui a à peu près le même résultat.

Ma question: est-ce que je manque quelque chose?Y a-t-il une utilisation judicieuse de la méthode getEon()?

Answer 1

Eh bien, d'après http://www.merlyn.demon.co.uk/critdate.htm l'heure unix utilisant un entier de 64 bits se terminera vers l'année 3E11.Étant donné que Java utilise des millisecondes au lieu de secondes, le temps Java (64 bits) se terminera autour de 3E8.Cela fournit donc une certaine extension au-delà des limites de la JVM.

Dans une note plus pratique, lorsque vous utilisez cette échelle de temps, vous parlez d'événements géologiques, évolutifs ou cosmologiques, donc le reste des données d'une date (année, mois, jour ...) n'a pas de sens.C'est mieux si vous utilisez un long avec l'année (ou même un int avec l'eon) et oubliez le reste.

On dirait que quelqu'un s'est vraiment, vraiment ennuyé (et ennuyeux).

---

Edit: Bien sûr, il y a toujours des problèmes fous qui peuvent l'utiliser, mais pas des problèmes du monde réel (comme dans: "si nous avons un Hanoi Towers avec 64 disques et déplacez un disque une seconde, quand finirions-nous d'échangerles tours ").