Meilleures pratiques en matière d'heure d'été et de fuseau horaire

Question

J'espère faire de cette question et des réponses qu'elle contient le guide définitif sur la gestion de l'heure d'été, en particulier sur la gestion du changement d'heure.

Si vous avez quelque chose à ajouter, n'hésitez pas à

De nombreux systèmes dépendent de la précision de l'heure. Le problème réside dans les changements d'heure dus à l'heure d'été, qui font avancer ou reculer l'horloge.

Par exemple, dans un système de prise de commandes, les règles de gestion dépendent de l'heure de la commande - si l'horloge change, les règles peuvent ne pas être aussi claires. Comment l'heure de la commande doit-elle être conservée ? Il existe bien sûr un nombre infini de scénarios - celui-ci n'est qu'une illustration.

• Comment avez-vous géré la question de l'heure d'été ?
• Quelles hypothèses font partie de votre solution ? (recherchez le contexte ici)

Aussi important, sinon plus :

• Qu'avez-vous essayé qui n'a pas fonctionné ?
• Pourquoi ça n'a pas marché ?

Je serais intéressé par la programmation, le système d'exploitation, la persistance des données et d'autres aspects pertinents de la question.

Les réponses générales sont très bien, mais j'aimerais aussi voir les détails, surtout s'ils ne sont disponibles que sur une seule plateforme.

Answer 1

Résumé des réponses et autres données : (veuillez ajouter les vôtres)

Faites :

• Chaque fois que vous vous référez à un moment précis dans le temps, conservez l'heure selon une norme unifiée qui n'est pas affectée par l'heure d'été. (GMT et UTC sont équivalents à cet égard, mais il est préférable d'utiliser le terme UTC. Notez que l'UTC est également connu sous le nom de Zulu ou Z temps.)
• Si vous choisissez plutôt de conserver une heure en utilisant une valeur d'heure locale, incluez le décalage de l'heure locale pour cette heure particulière par rapport à UTC (ce décalage peut changer au cours de l'année), de sorte que l'horodatage puisse être interprété ultérieurement sans ambiguïté.
• Dans certains cas, vous pouvez avoir besoin de stocker les deux l'heure UTC et l'heure locale équivalente. Souvent, cela se fait à l'aide de deux champs distincts, mais certaines plates-formes prennent en charge un champ de type datetimeoffset qui peut stocker les deux dans un seul champ.
• Lorsque vous stockez des horodatages sous forme de valeur numérique, utilisez la fonction Temps Unix - qui est le nombre de secondes entières depuis 1970-01-01T00:00:00Z (hors secondes intercalaires). Si vous avez besoin d'une plus grande précision, utilisez plutôt les millisecondes. Cette valeur doit toujours être basée sur UTC, sans ajustement de fuseau horaire.
• Si vous devez modifier ultérieurement l'horodatage, incluez l'ID du fuseau horaire d'origine afin de pouvoir déterminer si le décalage a pu changer par rapport à la valeur enregistrée à l'origine.
• Lors de la programmation d'événements futurs, l'heure locale est généralement préférée à l'heure UTC, car il est fréquent que le décalage change. Voir la réponse et article de blog .
• Lorsque vous enregistrez des dates entières, telles que des anniversaires, ne les convertissez pas en UTC ou en tout autre fuseau horaire.
  • Dans la mesure du possible, stockez dans un type de données de type date uniquement qui n'inclut pas d'heure de la journée.
  • Si un tel type n'est pas disponible, veillez à toujours ignorer l'heure du jour lorsque vous interprétez la valeur. Si vous ne pouvez pas être sûr que l'heure du jour sera ignorée, choisissez 12:00 Noon, plutôt que 00:00 Midnight comme heure représentative plus sûre de ce jour.
• N'oubliez pas que le décalage des fuseaux horaires n'est pas toujours un nombre entier d'heures (par exemple, l'heure normale indienne est UTC+05:30, et le Népal utilise UTC+05:45).
• Si vous utilisez Java, utilisez java.time pour Java 8 et plus.
  • Une grande partie de cette java.time est rétrocompatible avec Java 6 et 7 dans l'interface de l'utilisateur. Trois Dix-Backport bibliothèque.
  • Adaptation plus poussée pour les Android précoces (< 26) dans les ThreeTenABP bibliothèque.
  • Ces projets supplantent officiellement le vénérable Joda-Time maintenant dans mode maintenance . Joda-Time, ThreeTen-Backport, Trois-Dix-Extra , java.time et JSR 310 sont dirigés par le même homme, Stephen Colebourne .
• Si vous utilisez .NET envisagez d'utiliser Heure de Noda .
• Si vous utilisez .NET sans Noda Time, considérez que DateTimeOffset est souvent un meilleur choix que DateTime .
• Si vous utilisez Perl, utilisez DateTime .
• Si vous utilisez Python, utilisez pytz ou dateutil .
• Si vous utilisez JavaScript, utilisez moment.js avec le fuseau horaire extension.
• Si vous utilisez PHP > 5.2, utilisez les conversions de fuseaux horaires natives fournies par l'application DateTime et DateTimeZone classes. Soyez prudent lorsque vous utilisez DateTimeZone::listAbbreviations() - voir la réponse . Pour maintenir PHP avec des données Olson à jour, installez périodiquement le fuseau horaire Paquet PECL ; voir la réponse .
• Si vous utilisez le langage C++, assurez-vous d'utiliser une bibliothèque qui implémente correctement la fonction Base de données des fuseaux horaires de l'IANA . Il s'agit notamment de cctz , UNITÉ DE SOINS INTENSIFS et La bibliothèque "tz" de Howard Hinnant .
  • Ne pas utiliser Boost pour les conversions de fuseaux horaires. Alors que son API prétend prendre en charge les identifiants standard de l'IANA (alias "zoneinfo"). les cartographie grossièrement aux données de style POSIX, sans tenir compte de la riche histoire des changements que chaque zone a pu avoir. (De plus, le fichier est tombé en panne de maintenance).
• Si vous utilisez Rust, utilisez chrono .
• La plupart des règles commerciales utilisent l'heure civile, plutôt que l'UTC ou l'GMT. Par conséquent, prévoyez de convertir les horodatages UTC en fuseau horaire local avant d'appliquer la logique d'application.
• N'oubliez pas que les fuseaux horaires et les décalages ne sont pas fixes et peuvent changer. Par exemple, historiquement, les États-Unis et le Royaume-Uni utilisaient les mêmes dates pour "avancer" et "reculer". Toutefois, en 2007, les États-Unis ont modifié les dates de changement d'heure. Cela signifie désormais que pendant 48 semaines de l'année, la différence entre l'heure de Londres et l'heure de New York est de 5 heures et pendant 4 semaines (3 au printemps, 1 en automne), elle est de 4 heures. Tenez compte de ce genre d'éléments dans tout calcul impliquant plusieurs fuseaux horaires.
• Considérez le type de temps (temps réel de l'événement, temps de diffusion, temps relatif, temps historique, temps récurrent) et les éléments (horodatage, décalage du fuseau horaire et nom du fuseau horaire) que vous devez stocker pour une récupération correcte - voir "Types de temps" dans la section "Temps". cette réponse .
• Maintenez la synchronisation de votre système d'exploitation, de vos bases de données et des fichiers de données de vos applications, entre eux et le reste du monde.
• Sur les serveurs, réglez les horloges matérielles et les horloges du système d'exploitation sur UTC plutôt que sur un fuseau horaire local.
• Indépendamment du point précédent, le code côté serveur, y compris les sites web, doit jamais de s'attendre à ce que le fuseau horaire local du serveur soit quelque chose de particulier. voir la réponse .
• Préférez travailler avec les fuseaux horaires au cas par cas dans le code de votre application, plutôt que de manière globale par le biais des paramètres ou des valeurs par défaut du fichier de configuration.
• Utilisez NTP sur tous les serveurs.
• Si vous utilisez FAT32 Si vous avez besoin de plus d'informations, n'oubliez pas que les timestamps sont stockés en temps local, et non en UTC.
• Lorsqu'il s'agit d'événements récurrents (émission télévisée hebdomadaire, par exemple), n'oubliez pas que l'heure change avec l'heure d'été et qu'elle sera différente selon les fuseaux horaires.
• Demandez toujours les valeurs de date et d'heure sous forme de limite inférieure inclusive, limite supérieure exclusive ( >= , < ).

Ne le faites pas :

• Ne confondez pas un "fuseau horaire", tel que le America/New_York avec un "décalage de fuseau horaire", tel que -05:00 . Ce sont deux choses différentes. Voir la balise de fuseau horaire wiki .
• N'utilisez pas la fonction JavaScript Date pour effectuer des calculs de date et d'heure dans les navigateurs Web plus anciens, car ECMAScript 5.1 et les versions inférieures disposent d'un objet de date et d'heure. un défaut de conception qui peuvent utiliser l'heure d'été de manière incorrecte. (Ce problème a été corrigé dans ECMAScript 6 / 2015).
• Ne jamais se fier à l'horloge du client. Elle peut très bien être incorrecte.
• Ne dites pas aux gens de "toujours utiliser l'UTC partout". Ce conseil très répandu ne tient pas compte de plusieurs scénarios valables qui sont décrits plus haut dans ce document. Utilisez plutôt la référence temporelle appropriée pour les données avec lesquelles vous travaillez. ( Horodatage peuvent utiliser l'UTC, mais les programmations temporelles futures et les valeurs de type date uniquement ne doivent pas l'être).

Test :

• Lorsque vous effectuez des tests, veillez à tester les pays de l'Ouest, de l'Est, du Nord et de l'Ouest de l'Europe. Sud hémisphères (en fait dans chaque quart du globe, donc 4 régions), avec l'heure d'été en cours ou non (ce qui donne 8), et un pays qui n'utilise pas l'heure d'été (4 de plus pour couvrir toutes les régions, soit 12 au total).
• Testez la transition de l'heure d'été, c'est-à-dire que si vous êtes actuellement en heure d'été, sélectionnez une valeur d'heure d'hiver.
• Tester les cas limites, tels qu'un fuseau horaire qui est UTC+12, avec DST, rendant l'heure locale UTC+13 en été et même des endroits qui sont UTC+13 en hiver.
• Testez toutes les bibliothèques et applications tierces et assurez-vous qu'elles gèrent correctement les données relatives aux fuseaux horaires.
• Testez les fuseaux horaires d'une demi-heure, au moins.

Référence :

• Le détail timezone Page wiki du tag sur Stack Overflow
• Base de données Olson, alias Tz_database
• Projet de procédures de l'IETF pour la maintenance de la base de données Olson
• Sources pour le fuseau horaire et l'heure d'été
• Format ISO (ISO 8601)
• Correspondance entre la base de données Olson et les identifiants de fuseau horaire de Windows, du Consortium Unicode.
• Page sur les fuseaux horaires dans Wikipédia
• Questions StackOverflow étiquetées dst
• Questions StackOverflow étiquetées timezone
• Gestion de l'heure d'été - Meilleures pratiques de Microsoft DateTime
• Network Time Protocol sur Wikipédia

Autre :

• Faites pression sur votre représentant pour mettre fin à l'abomination qu'est l'heure d'été. On peut toujours espérer...
• Lobby pour Heure normale de la Terre

Answer 2

Je ne sais pas trop ce que je peux ajouter aux réponses ci-dessus, mais voici quelques points de mon point de vue :

Types de temps

Il y a quatre moments différents que vous devriez considérer :

1. Heure de l'événement : par exemple, l'heure à laquelle un événement sportif international a lieu, ou un couronnement/décès/etc. Cela dépend du fuseau horaire de l'événement et non de celui du téléspectateur.
2. Heure de la télévision : par exemple, une émission de télévision particulière est diffusée à 21 heures, heure locale, dans le monde entier. Important lorsque vous envisagez de publier les résultats (de l'émission American Idol, par exemple) sur votre site web.
3. Temps relatif : ex : Cette question a un bounty ouvert qui se termine dans 21 heures. Ceci est facile à afficher
4. Temps récurrent : ex : Une émission de télévision est diffusée tous les lundis à 21 heures, même lorsque l'heure d'été change.

Il y a aussi le temps historique/alternatif. Elles sont ennuyeuses car elles ne correspondent pas toujours à l'heure standard. Par exemple : les dates juliennes, les dates selon un calendrier lunaire sur Saturne, le calendrier klingon.

Le stockage des horodatages de début et de fin en UTC fonctionne bien. Pour 1, vous avez besoin d'un nom de fuseau horaire + un décalage stockés avec l'événement. Pour le 2, vous avez besoin d'un identifiant d'heure locale stocké avec chaque région et d'un nom de fuseau horaire local + décalage stocké pour chaque spectateur (il est possible de le dériver à partir de l'IP si vous êtes dans une situation difficile). Pour 3, le stockage se fait en secondes UTC et les fuseaux horaires ne sont pas nécessaires. Le point 4 est un cas particulier de 1 ou 2, selon qu'il s'agit d'un événement global ou local, mais vous devez également stocker un nom de fuseau horaire et un décalage pour chaque spectateur. créé à L'horodatage vous permet de savoir si une définition de fuseau horaire a été modifiée avant ou après la création de cet événement. Ceci est nécessaire si vous avez besoin de montrer des données historiques.

Temps de stockage

• Toujours stocker l'heure en UTC
• Conversion en heure locale à l'affichage (l'heure locale étant définie par l'utilisateur qui regarde les données).
• Pour stocker un fuseau horaire, vous avez besoin du nom, de l'horodatage et du décalage. Cela est nécessaire parce que les gouvernements changent parfois la signification de leurs fuseaux horaires (par exemple, le gouvernement américain a changé les dates de l'heure d'été), et votre application doit gérer les choses de manière élégante... par exemple : L'horodatage exact de la diffusion des épisodes de LOST avant et après le changement des règles de l'heure d'été.

Offsets et noms

Un exemple de ce qui précède serait :

Le match de la finale de la coupe du monde de football a eu lieu en Afrique du Sud (UTC+2--SAST) le 11 juillet 2010 à 19:00 UTC.

Grâce à ces informations, nous pouvons historiquement déterminer l'heure exacte à laquelle la finale des WCS 2010 a eu lieu, même si la définition du fuseau horaire sud-africain change, et être en mesure de l'afficher aux téléspectateurs dans leur fuseau horaire local au moment où ils interrogent la base de données.

Heure du système

Vous devez également veiller à la synchronisation de votre système d'exploitation, de votre base de données et de vos fichiers de données applicatives, tant entre eux qu'avec le reste du monde, et effectuer des tests approfondis lors des mises à niveau. Il n'est pas rare qu'une application tierce dont vous dépendez ne gère pas correctement un changement de TZ.

Assurez-vous que les horloges matérielles sont réglées sur UTC et, si vous utilisez des serveurs dans le monde entier, assurez-vous que leurs systèmes d'exploitation sont également configurés pour utiliser UTC. Cela devient évident lorsque vous devez copier des fichiers journaux apache à rotation horaire à partir de serveurs situés dans plusieurs fuseaux horaires. Les trier par nom de fichier ne fonctionne que si tous les fichiers sont nommés avec le même fuseau horaire. Cela signifie également que vous n'avez pas à faire de calculs de date dans votre tête lorsque vous vous connectez en ssh d'une boîte à une autre et que vous devez comparer les horodatages.

Lancez aussi ntpd sur toutes les boîtes.

Clients

Ne croyez jamais que l'horodatage que vous obtenez d'une machine cliente est valide. Par exemple, les en-têtes HTTP Date :, ou un javascript Date.getTime() appel. Ces valeurs sont acceptables lorsqu'elles sont utilisées comme identifiants opaques ou lorsqu'elles sont utilisées pour calculer des dates au cours d'une session unique sur le même client, mais n'essayez pas de les comparer à des valeurs que vous avez sur le serveur. Vos clients n'utilisent pas NTP et n'ont pas nécessairement une batterie en état de marche pour leur horloge BIOS.

Trivia

Enfin, les gouvernements font parfois des choses très bizarres :

L'heure normale aux Pays-Bas était exactement 19 minutes et 32,13 secondes en avance sur l'UTC par la loi de 1909-05-01 jusqu'au 30 juin 1937. Ce fuseau horaire ne peut pas être représenté exactement en utilisant le format HH:MM.

Ok, je pense que j'ai fini.

Answer 3

Il s'agit d'une question importante et étonnamment difficile. La vérité est qu'il n'existe pas de norme totalement satisfaisante pour la persistance du temps. Par exemple, la norme SQL et le format ISO (ISO 8601) ne sont clairement pas suffisants.

D'un point de vue conceptuel, on a généralement affaire à deux types de données temps-date, et il est pratique de les distinguer (les normes ci-dessus ne le font pas) : " temps physique " et " temps civil ".

Un instant de temps "physique" est un point de la ligne de temps universelle continue que la physique traite (en ignorant la relativité, bien sûr). Ce concept peut être codé de manière adéquate en UTC, par exemple (si vous pouvez ignorer les secondes intercalaires).

Une heure "civile" est une spécification de date-heure qui suit les normes civiles : un point de temps est ici entièrement spécifié par un ensemble de champs de date-heure (Y,M,D,H,MM,S,FS) plus un TZ (spécification de fuseau horaire) (également un "calendrier", en fait ; mais supposons que nous restreignons la discussion au calendrier grégorien). Un fuseau horaire et un calendrier permettent conjointement (en principe) de passer d'une représentation à une autre. Mais les instants de temps civil et physique sont des types de grandeurs fondamentalement différents, et ils doivent être maintenus conceptuellement séparés et traités différemment (une analogie : tableaux d'octets et chaînes de caractères).

La question est confuse parce que nous parlons de ces types d'événements de manière interchangeable, et parce que les temps civils sont sujets à des changements politiques. Le problème (et la nécessité de distinguer ces concepts) devient plus évident pour les événements à venir. Exemple (tiré de ma discussion ici .

Jean enregistre dans son calendrier un rappel pour un événement à une date donnée. 2019-Jul-27, 10:30:00 , TZ= Chile/Santiago (qui a le décalage GMT-4, il correspond donc à UTC 2019-Jul-27 14:30:00 ). Mais un jour dans le futur, le pays décide de changer le décalage TZ en GMT-5.

Maintenant, quand le jour arrive... est-ce que ce rappel doit se déclencher à...

A) 2019-Jul-27 10:30:00 Chile/Santiago = UTC time 2019-Jul-27 15:30:00 ?

ou

B) 2019-Jul-27 9:30:00 Chile/Santiago = UTC time 2019-Jul-27 14:30:00 ?

Il n'y a pas de réponse correcte, sauf si l'on sait ce que Jean voulait dire conceptuellement quand il a dit au calendrier "S'il vous plaît, appelez-moi au 2019-Jul-27, 10:30:00 TZ=Chile/Santiago ".

Voulait-il dire une "date-heure civile" ("quand les horloges de ma ville indiquent 10:30") ? Dans ce cas, A) est la bonne réponse.

Ou voulait-il dire un "instant physique du temps", un point dans la ligne continue du temps de notre univers. continue de notre univers, disons, "quand la prochaine éclipse solaire se produira". Dans ce cas, la réponse B) est la bonne.

Quelques API de date et d'heure font bien cette distinction, notamment, Jodatime qui constitue la base de la prochaine (troisième !) API Java DateTime (JSR 310).

Answer 4

Établir une séparation architecturale claire des préoccupations - pour savoir exactement quel niveau interagit avec les utilisateurs, et doit changer la date et l'heure pour/depuis la représentation canonique (UTC). La date et l'heure non UTC sont présentées (suit le fuseau horaire local des utilisateurs), L'heure UTC est un modèle (reste unique pour le back-end et le mid tier).

Aussi, décidez quel est votre public réel, ce que vous n'avez pas à servir et où se situe la limite. . Ne touchez pas aux calendriers exotiques, à moins que vous n'ayez des clients importants dans cette région, et envisagez alors un ou plusieurs serveurs distincts pour cette région.

Si vous pouvez obtenir et conserver l'emplacement de l'utilisateur, utilisez cet emplacement pour la conversion systématique de la date et de l'heure (par exemple, la culture .NET ou une table SQL), mais offrez à l'utilisateur final la possibilité de choisir des remplacements si la date et l'heure sont essentielles pour vos utilisateurs.

S'il existe des obligations d'audit historiques impliqué (comme dire exactement quand Jo en AZ a payé une facture il y a 2 ans en septembre) puis conserver à la fois l'heure UTC et l'heure locale pour mémoire (vos tables de conversion vont changer au fil du temps).

Définir le fuseau horaire de référence pour les données qui arrivent en vrac - comme les fichiers, les services web, etc. Supposons qu'une entreprise de la côte Est possède un centre de données en Californie. Vous devez demander et savoir ce qu'ils utilisent comme norme au lieu de supposer l'un ou l'autre.

Ne vous fiez pas aux décalages de fuseaux horaires intégrés dans la représentation textuelle de la date, de l'heure et de l'heure. n'acceptez pas de les analyser et de les suivre. Au lieu de cela, demandez toujours que le fuseau horaire et/ou la zone de référence soient explicitement définis. . Vous pouvez facilement recevoir l'heure avec le décalage PST mais l'heure est en fait EST puisque c'est l'heure de référence du client et que les enregistrements ont juste été exportés sur un serveur qui est en PST.

Answer 5

Vous devez connaître l'Olson base de données tz qui est disponible auprès de ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/ . Il est mis à jour plusieurs fois par an pour tenir compte des changements de dernière minute concernant le passage de l'heure d'hiver à l'heure d'été (heure normale et heure d'été) dans différents pays du monde. En 2009, la dernière version était 2009s ; en 2010, c'était 2010n ; en 2011, c'était 2011n ; à la fin du mois de mai 2012, la version était 2012c. Notez qu'il existe un ensemble de code pour gérer les données et les données de fuseau horaire elles-mêmes, dans deux archives séparées (tzcode20xxy.tar.gz et tzdata20xxy.tar.gz). Le code et les données sont tous deux dans le domaine public.

C'est la source des noms de fuseaux horaires tels que America/Los_Angeles (et des synonymes tels que US/Pacific).

Si vous devez assurer le suivi de différentes zones, vous avez besoin de la base de données Olson. Comme d'autres l'ont conseillé, vous souhaitez également stocker les données dans un format fixe - UTC est normalement le format choisi - ainsi qu'un enregistrement du fuseau horaire dans lequel les données ont été générées. Vous voudrez peut-être faire la distinction entre le décalage par rapport à l'UTC à l'époque et le nom du fuseau horaire ; cela peut faire une différence par la suite. De même, le fait de savoir que nous sommes actuellement en 2010-03-28T23:47:00-07:00 (US/Pacifique) peut ou non vous aider à interpréter la valeur 2010-11-15T12:30 - qui est vraisemblablement spécifiée en PST (Pacific Standard Time) plutôt qu'en PDT (Pacific Daylight Saving Time).

Les interfaces de la bibliothèque C standard ne sont pas d'une aide redoutable pour ce genre de choses.

---

Les données Olson ont été déplacées, en partie parce que A D Olson va bientôt prendre sa retraite, et en partie parce qu'une action en justice (aujourd'hui rejetée) a été intentée contre les responsables pour violation des droits d'auteur. La base de données des fuseaux horaires est maintenant gérée sous les auspices de IANA l'Internet Assigned Numbers Authority, et il y a un lien sur la page d'accueil pour Base de données des fuseaux horaires . La liste de diffusion pour la discussion est maintenant tz@iana.org ; la liste des annonces est tz-announce@iana.org .