Comment obtenir le Temps Atomique international en Java 7

Le backport JSR-310 ne prend en charge que les fonctionnalités qui seront incluses dans Java 8. TAI (et true UTC) ne sera pas une fonctionnalité prise en charge, il ne peut donc pas être en backport. La seule alternative serait d'essayer le threeten-extra-project qui contient la classe TAIInstant mais l'ensemble du projet supplémentaire pourrait ne pas être à jour (code très ancien).

Je travaille moi-même sur ma bibliothèque Time4J qui prend en charge TAI, GPS et UTC en plus de POSIX.

[MISE À JOUR de juillet 2014 : Time4J est maintenant disponible en version stabletime4j-v1.0 . Ce débat a été pris en compte - voir par exemple Moment.toString(Échelle de temps) .]

Correction et remarques détaillées aux questions nouvellement postées du PO:

A) Oui, le TAI augmente de façon monotone en unités de SI-secondes, même pendant les secondes intercalaires. Si c'est seulement ce que vous voulez, vous pouvez choisir TAI, mais il y a un piège. Si vous voulez décrire les horodatages civils alors TAI donnera vous vous trompez d'horodatage (comparez simplement la première et la deuxième colonne du diagramme Wikipedia). La raison en est simplement que la vie civile est régie par UTC, pas TAI.

B) À propos de mes commentaires selon lesquels le diagramme de Wikipédia est faux, je l'ai regardé de très près et j'ai changé d'avis. La relation entre POSIX et TAI n'est pas fixe (décalage de 10s seulement en 1972), veuillez donc excuser mon erreur. Jusqu'à présent, je n'ai pas tellement pensé à TAI, plutôt à POSIX et UTC. Mais merci pour la question et ce débat éclairant donc vous méritez mon vote positif. Le tout est délicat. Lorsque nous parlons d'horodatages représentés dans différentes échelles de temps, nous devons faire une différence entre le formulaire ymdhms et le formulaire epochsecs. Considérons - le en détail pour le temps 1999-01-01T00:00:00Z (UTC-scale):

  i) TAI = (29 * 365 + 7) days * 86400 + 22 leap seconds + 10s (offset at 1972) = 915148832
 ii) UTC = TAI - 10 = 915148822 (fixed relation between UTC and TAI on epoch-second-level)
iii) POSIX = UTC - 22 leap seconds = 915148800

=> (ymdhms-form);
  i) TAI (915148800 + 32) = 1999-01-01T00:00:32 (based on TAI-"day" = 86400 SI-secs)
 ii) UTC = 1999-01-01T00:00:00 (stripped off former 22 leap secs in conversion to ymdhms)
iii) POSIX = 1999-01-01T00:00:00 (fixed relation between UTC and POSIX with exception of leapsecs)

Alors pourquoi l'affirmation selon laquelle TAI ne compte pas les secondes intercalaires? Il ne compte pas les sauts dans ymdhms-form, mais bien sûr il les compte sur epoch-second-level (monotonicité exigence!). Et POSIX? Il ne compte pas du tout les secondes intercalaires, ni sous forme ymdhms ni au niveau epoch-secondes. Donc finalement nous n'avons pas de relation fixe entre TAI et POSIX. Une table de seconde bissextile est requise pour la conversion.

C) Que dit la spécification POSIX sur le comportement de la seconde intercalaire? Voir ici. Notez en particulier la déclaration: "La relation entre l'heure réelle de la journée et la valeur actuelle pour les secondes depuis l'époque n'est pas spécifiée."Cela concerne donc aussi la seconde bissextile. Il appartient aux implémentations d'horloge si elles sautent avant la seconde de saut ou sautent après ou gèlent pendant une seconde.

D) Oui, System.currentTimeMillis() obtiendra l'équivalent du temps POSIX (mais en millisecondes plutôt qu'en secondes).

E) Juste pour noter, le label TAI n'est pas défini avant 1971 et le Temps atomique international pas avant 1958, donc l'échelle proleptique de threeten-extra-classe TAIInstant est en quelque sorte un non-sens. Je n'appliquerais donc pas le TAI avant 1972. Me voilà avec Steve Allen, l'expert du temps Scales.

F) Si vous avez besoin d'un objet temporel "portable entre JVM et machines", UTC lui-même nécessite la distribution/existence de la même table de seconde bissextile partout. Si vous choisissez TAI, vous avez toujours besoin de cette table de deuxième saut afin d'activer les applications pour convertir les horodatages TAI en horodatages UTC ou POSIX. Je doute donc que vous puissiez avoir un horodatage monotone et ignorer simultanément les secondes intercalaires. TAI n'offre pas de solution pour cela dilemme.

Les Réponses à la question/résumé de l'OP de 2013-12-31:

Vos résumés sur TAI et POSIX sont corrects.

A propos de UTC, vous devez surtout comprendre que UTC est un compromis. D'un côté, il est conçu pour suivre le soleil, de l'autre côté, le second sur l'échelle UTC est exactement le même que sur l'échelle TAI, à savoir la SI-seconde (définition atomique). Vous avez raison lorsque vous avez déclaré que la vitesse de rotation de la terre ralentit de manière imprévisible, donc les secondes sautent sont quelques fois inséré. La différence entre UT1 (temps solaire moyen) et UTC doit toujours être inférieure à 0,9 SI-secondes. Donc, ceci et le fait de secondes SI égales sont les idées fondamentales de UTC. En aparté, l'adaptation de l'échelle exotique UTC-SLS dans JSR - 310 n'est pas compatible avec ces idées fondamentales de l'UTC. A propos de la prévisibilité des secondes intercalaires, le BIPM à Paris annonce chaque semestre si 6 mois plus tard il y aura une seconde intercalaire nécessaire ou non, donc vous avez ce cadre de prévisibilité de six mois à l'avance.

Une correction peut-être pédante à propos de la section UTC, vous avez écrit: "le Soleil est toujours à son plus haut à midi UTC."Une déclaration similaire est également donnée dans le javadoc de la classe java.temps.Instant sur la soi-disant échelle de temps java. Mis à part le fait, que vous ne vouliez sûrement pas dire que la position du soleil est indépendante de votre position locale, elle n'est même pas correcte à la longitude droite à midi. Pourquoi? D'un point de vue astronomique / scientifique vous il faut d'abord ne pas oublier que l'heure solaire moyenne du soleil n'est pas la même que l'heure solaire locale réelle que vous regardez (en donnant simplement le mot-clé "équation du temps"). De plus, puisque UTC est toujours basé sur le temps atomique et utilise le temps atomique pour la synchronisation, il existe une relation dite delta-T entre UT1 et UTC. Ce delta est dans le cadre de 0.9 secondes et est publié régulièrement parERS / BIPM dans le bulletin B. Vous devez connaître ce delta lorsque vous voulez obtenir la position réelle du soleil et quand le soleil est le plus haut.

La section "Représenter les temps" est à mon avis un peu trop simple. D'accord, on peut dire que TAI et POSIX comptent les secondes alors que UTC est plutôt représenté en année / mois/jour/...-forme. Mais nous pouvons en effet appliquer les deux représentations à toutes les échelles. Mais nous devons soigneusement différencier ces représentations et réfléchir à la façon de convertir. Notez que Wikipedia a même choisi le formulaire ymdhms pour TAI dans les diagrammes. Eh bien, les ordinateurs peuvent mieux stockez des entiers simples. Et POSIX ou TAI peuvent facilement être stockés dans ce format. Mais comme je l'ai déjà dit, l'interprétation de ces entiers n'est pas toujours simple. Dans le cas de TAI, vous avez même besoin d'une table de seconde bissextile pour convertir en ymdhms-form civil lisible (UTC ou POSIX).

A propos de la section suivante "Temps de traduction", je suis d'accord avec les points 1-3.

Votre déclaration finale "D'autre part, il est facile de convertir de POSIX à l'UTC 'interprétation humaine'."est à droite, à l'exception de secondes intercalaires. Eh bien, j'active une traduction appropriée entre les différentes échelles avec ma bibliothèque à venir. Il a une table de deuxième saut intégrée mais configurable, et à l'avenir, je prévois également d'utiliser IANA-TZDB-data comme source pour une telle table.

Dans l'ensemble, soyez conscient du fait que la plupart des développeurs d'affaires n'ont pas besoin d'autant de précision. La plupart des gens vont simplement égaliser POSIX et UTC et seront probablement satisfaits de toutes les solutions matérielles de lissage dans Linux OS ou sur les serveurs Google NTP. Vrai UTC et TAI (qui prend en compte les secondes intercalaires) nécessitent plus d'efforts. Vous devez donc décider si votre architecture logicielle nécessite une précision scientifique.

Et juste pour noter, JSR-310 ne traite officiellement pas du tout de l'échelle très étendue POSIX, au lieu de cela, ils disent que leur instant de classe doit être UTC-SLS par définition (voir aussi cet intéressant débat).

Enfin, je suis gracieux pour cette discussion. Cela m'a également aidé à clarifier mes pensées sur le TAI dans mon bibliothèque. Grâce.