Identification des fuseaux horaires dans ISO 8601

Question

Non, je ne parle pas des décalages de zone --- ceux-ci peuvent varier au cours de l'année pour une région en fonction, par exemple, DST. Je parle du réel fuseaux horaires maintenus par l'IANA . Je comprends que ce ne sont pas pris en charge par ISO 8601, correct?

Que font les plates-formes pour prendre en charge l'identification des fuseaux horaires dans les représentations de chaînes de type ISO 8601? Je remarque que la dernière bibliothèque Java date/heure utilise un format ISO 8601 étendu pour cela, par exemple 2011-12-03T10:15:30+01:00[Europe/Paris]. (Voir API DateTimeFormatter .)

Existe-t-il une convention convergente (par exemple avec d'autres langages et plates-formes) pour étendre ISO 8601 pour prendre en charge la désignation de fuseau horaire?

Matt Johnson-Pint · Answer

Je comprends que ceux-ci ne sont pas pris en charge par ISO 8601, n'est-ce pas?

Correct. ISO-8601 ne se préoccupe pas des identificateurs de fuseau horaire. Les noms IANA/Olson TZ ne sont pas un "standard". Ils sont juste la chose la plus fiable que nous ayons. (Certains peuvent les considérer comme la norme de facto.)

Que font les plateformes pour supporter cela?

Soutenez quoi exactement? Cette partie de votre question n'est pas claire. Si vous voulez soutenir les fuseaux horaires de l'IANA, eh bien c'est partout. Certaines plateformes les intègrent et certaines s'appuient sur des bibliothèques. Si vous envisagez de prendre en charge une représentation sous forme de chaîne d'un ID date-heure + décalage horaire ISO-8601, certaines plates-formes en disposent et d'autres non. Vous devrez être plus précis si vous voulez en savoir plus.

Je remarque que la dernière bibliothèque Java date/heure utilise un format ISO 8601 étendu pour cela, par exemple 2011-12-03T10: 15: 30 + 01: 00 [Europe/Paris]. ( Voir API DateTimeFormatter.)

Je pense que vous parlez de DateTimeFormatter.ISO_ZONED_DATE_TIME . Les documents disent spécifiquement:

L'ISO - comme formateur date-heure ...

... étend le format date-heure de décalage étendu ISO-8601 pour ajouter le fuseau horaire. La section entre crochets ne fait pas partie de la norme ISO-8601.

C'est donc le format spécifique de Java, pas un standard.

Existe-t-il une convention convergente (par exemple avec d'autres langages et plates-formes) pour étendre ISO 8601 pour prendre en charge la désignation de fuseau horaire?

Pour autant que je sache, il n'existe actuellement aucune norme qui couvre la combinaison d'un horodatage ISO8601 et d'un identifiant de fuseau horaire IANA dans un format unique. On pourrait le représenter de différentes manières, notamment:

2011-12-03T10:15:30+01:00[Europe/Paris] (C'est la valeur par défaut dans Java 8)
2011-12-03T10:15:30+01:00(Europe/Paris)
2011-12-03T10:15:30+01:00 Europe/Paris
2011-12-03T10:15:30+01:00 - Europe/Paris
2011-12-03T10:15:30+01:00/Europe/Paris
2011-12-03T10:15:30+01:00|Europe/Paris
2011-12-03T10:15:30 Europe/Paris (+01) (c'est la valeur par défaut dans Noda Time)

Si ce que vous recherchez est un moyen d'inclure un ZonedDateTime ou des données similaires dans une API de manière standardisée, ma recommandation personnelle serait de passer le nom du fuseau horaire dans un champ séparé. De cette façon, chaque partie de données est aussi bonne que possible. Par exemple en JSON:

{ "timestamp": "2011-12-03T10:15:30+01:00", "timezone": "Europe/Paris" }

Basil Bourque · Answer

Le Réponse de Matt Johnson est parfait. Je vais juste ajouter quelques réflexions.

Fuseau horaire versus décalage par rapport à l'UTC

Un offset-from-UTC est simplement un nombre d'heures, de minutes et de secondes devant/derrière UTC . Seul, cela fait de la date-heure un moment précis de la chronologie. Mais ce n'est pas aussi informatif que d'inclure le nom du fuseau horaire officiel .

Bien qu'il n'y ait pas encore de norme pour inclure le nom du fuseau horaire, j'espère que d'autres suivront l'exemple des classes Java.time en ajoutant entre crochets le nom du fuseau horaire. Ce format me semble judicieux car il serait simple de tronquer la partie entre crochets pour être rétrocompatible avec les logiciels non avertis.

Par exemple:
2011-12-03T10:15:30+01:00[Europe/Paris]. Si les données n'étaient que 2011-12-03T10:15:30+01:00, nous pourrions identifier le moment sur la chronologie, mais nous ne pourrions pas ajuster d'autres moments dans le même état d'esprit car nous ne saurions pas quelles règles d'ajustement appliquer. Des zones telles que Europe/Zagreb, Africa/Brazzaville, Arctic/Longyearbyen, et Europe/Isle_of_Man partagent tous le décalage de +01:00, mais ils pourraient bien avoir d'autres ajustements en vigueur différents de ceux de Europe/Paris. Donc, si vous essayez d'ajouter trois jours à la valeur 2011-12-03T10:15:30+01:00, vous ne pouvez vraiment pas calculer fidèlement le résultat, car vous ne savez pas quels ajustements peuvent être nécessaires, tels que les coupures d'heure d'été qui peuvent se produire pendant ces trois jours.

Un fuseau horaire définit l'ensemble des règles de gestion des anomalies telles que heure d'été (DST) . Les politiciens du monde entier aiment ajuster leurs fuseaux horaires, voire les redéfinir. Ces règles changent donc fréquemment. Considérez un fuseau horaire comme une collection de décalages au fil du temps, de nombreuses périodes de temps dans lesquelles chaque période avait un décalage particulier utilisé dans cette région particulière.

Vous pouvez considérer un fuseau horaire comme une collection de valeurs de décalage par rapport à UTC. Dans America/Los_Angeles une partie de cette année a 8 heures de retard sur UTC, et une partie de l'année aura 7 heures de retard sur UTC. Cela fait 2 points de données collectés dans le cadre de ce fuseau horaire.

Un autre exemple, les années précédentes, la Turquie a passé une partie de chaque année 2 heures d'avance sur UTC et une partie de chaque année 3 heures d'avance. En 2016, cela a changé pour rester indéfiniment 3 heures à l'avance. Ainsi, plusieurs points de données dans le fuseau horaire Europe/Istanbul .

Utilisez simplement UTC

Personnellement, je ne vois pas beaucoup de valeur même en utilisant des valeurs telles que 2011-12-03T10:15:30+01:00. Sans fuseau horaire, vous pourriez tout aussi bien utiliser UTC seul. Dans ce cas, 2011-12-03T09:15:30Z (9 h au lieu de 10 h).

En règle générale, la meilleure pratique consiste à utiliser UTC lors du stockage et de l'échange de valeurs date-heure. Considérez l'UTC comme le temps réel unique , les valeurs zonées ou décalées étant de simples variations.