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

:

• chaque fois que vous vous référez à un moment précis dans le temps, persistez l'heure selon une norme unifiée qui n'est pas affectée par l'heure d'été. (GMT et UTC sont équivalents à ce sujet, mais il est préférable d'utiliser le terme UTC. Notez que UTC est également connu sous le nom de Zulu ou Z du temps.)
• si au lieu de cela vous choisissez de persister un temps en utilisant une valeur locale de temps, inclure l'heure locale offset pour cette heure particulière de UTC (cet offset peut changer tout au long de l'année), de sorte que l'horodatage peut être interprété plus tard sans ambiguïté.
• dans certains cas, vous pouvez avoir besoin de stocker à la fois L'heure TUC et l'heure locale équivalente. Souvent, cela se fait avec deux champs distincts, mais certaines plates-formes prennent en charge un type datetimeoffset qui peut stocker les deux dans un seul champ.
• pour stocker les horodateurs en tant que valeur numérique, utilisez Unix time - qui est le nombre de secondes entières depuis 1970-01-01T00:00:00Z (à l'exclusion des secondes intercalaires). Si vous avez besoin de plus de précision, utilisez des millisecondes à la place. Cette valeur doit toujours être basée sur UTC, sans ajustement de fuseau horaire.
• si vous pourriez avoir besoin plus tard de modifier la timestamp, incluez L'ID du fuseau horaire original pour que vous puissiez déterminer si le décalage peut avoir changé par rapport à la valeur originale enregistrée.
• lors de la planification d'événements futurs, l'heure locale est habituellement préférée à L'heure TUC, car il est courant que la compensation change. Voir la réponse , et blog post .
• lorsque vous stockez des dates entières, comme les anniversaires et les anniversaires, ne convertissez pas en UTC ou à tout autre moment zone.
  • si possible, stocker dans un type de données date-only qui ne comprend pas une heure de la journée.
  • Si ce type n'est pas disponible, assurez-vous de toujours ignorer l'heure de la journée lors de l'interprétation de la valeur. Si vous ne pouvez pas être assuré que l'Heure de la journée sera ignorée, choisissez midi plutôt que minuit comme heure représentative plus sûre ce jour-là.
• rappelez-vous que le fuseau horaire compense ne sont 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.heure pour Java 8, ou utilisez Joda Time pour Java 7 ou inférieur.
• si vous utilisez .NET , envisagez d'utiliser Heure de Noda .
• si vous utilisez .NET sans aucun délai, 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 l'extension moment-fuseau horaire .
• si vous utilisez PHP > 5.2, utilisez les conversions des fuseaux horaires natifs fourni par les classes DateTime et DateTimeZone . Soyez prudent lorsque vous utilisez DateTimeZone::listAbbreviations() - voir la réponse . Pour garder PHP avec des données Olson à jour, installez périodiquement le paquet timezonedb PECL; voir réponse .
• si vous utilisez C++, assurez-vous d'utiliser une bibliothèque qui utilise correctement la base de données IANA timezone . Il s'agit notamment de cctz , ICU , et Howard Hinnant "tz" bibliothèque .
  • N'utilisez pas Boost pour les conversions de fuseaux horaires. Alors que its API prétend supporter les identificateurs standard IANA (alias "zoneinfo"), il les mappe grossièrement à des données de style POSIX, sans tenir compte de la riche histoire des changements que chaque zone a pu avoir. (Par ailleurs, le fichier est tombé de l'entretien.)
• si vous utilisez la rouille, utilisez chrono .
• la plupart des règles d'affaires utilisent l'heure civile, plutôt que L'heure TUC ou GMT. Par conséquent, projetez de convertir UTC horodatage à un fuseau horaire local avant d'appliquer la logique d'application.
• Rappelez-vous 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 ont utilisé les mêmes dates pour "spring forward" et "fall back". Cependant, en 2007, les États-Unis ont changé les dates auxquelles les horloges sont changées. Cela signifie que pour 48 semaines de l'année la différence entre le temps de Londres et le temps de New York est de 5 heures et pour 4 semaines (3 au printemps, 1 à l'automne) il est de 4 heures. Soyez conscient des éléments comme celui-ci dans tous les calculs qui impliquent plusieurs zones.
• tenir compte du type d'heure (heure réelle de l'événement, Heure de diffusion, heure relative, heure historique, heure récurrente) quels éléments (horodatage, décalage du fuseau horaire et le nom du fuseau horaire) vous devez stocker pour la récupération correcte-voir "Types de temps" dans cette réponse .
• synchronisez votre système D'exploitation, votre base de données et vos fichiers tzdata d'application, entre eux et le reste du monde.
• sur les serveurs, réglez les horloges matérielles et OS sur UTC plutôt que sur un fuseau horaire local.
• indépendamment du point de puce précédent, code côté serveur, y compris sites web, devrait jamais s'attendre à ce que le fuseau horaire local du serveur soit quelque chose en particulier. voir réponse .
• préfèrent travailler avec des fuseaux horaires au cas par cas dans votre code d'application, plutôt que globalement par des paramètres de fichier de configuration ou par défaut.
• Use NTP services sur tous les serveurs.
• si vous utilisez FAT32 , rappelez-vous que les horodateurs sont stockés en heure locale, pas UTC.
• lors d'événements récurrents (émission de télévision hebdomadaire, par exemple), rappelez-vous que l'heure change avec la DST et sera différente selon les fuseaux horaires.
• toujours interroger les valeurs date-heure comme limite inférieure inclusive, limite supérieure exclusive ( >= , < ).

à Ne pas faire:

• Ne pas confondre un "fuseau horaire", comme America/New_York avec un "décalage horaire", comme -05:00 . Ils sont deux choses différentes. Voir l'étiquette de timezone wiki .
• N'utilisez pas L'objet Date de JavaScript pour effectuer des calculs de date et d'heure dans les navigateurs Web plus anciens, comme ECMAScript 5.1 et inférieur a un défaut de conception qui peut utiliser l'heure d'été incorrectement. (Ceci a été corrigé dans ECMAScript 6 / 2015).
• ne faites jamais confiance à l'horloge du client. Il se peut très bien que ce soit incorrect.
• ne dites pas aux gens de"toujours utiliser UTC partout". Cet avis général est à courte vue de plusieurs scénarios valables qui sont décrits plus haut dans le présent document. Utilisez plutôt la référence de temps appropriée pour les données avec lesquelles vous travaillez. ( Timestamping peut utiliser UTC, mais l'établissement futur du calendrier et des valeurs date-only devrait pas.)

test:

• lors des tests, assurez-vous de tester des pays dans les hémisphères Ouest, Est, Nord et Sud (en fait dans chaque quart du globe, donc 4 régions), avec à la fois DST en cours et pas (donne 8), et un pays qui n'utilise pas DST (4 autres pour couvrir toutes les régions, ce qui fait 12 au total).
• essai de transition DST, c'est-à-dire lorsque vous êtes actuellement en heure d'été, sélectionnez une valeur horaire à partir de l'hiver.
• cas limites D'essai, comme un fuseau horaire qui est UTC+12, avec DST, ce qui rend l'heure locale UTC+13 en été et même les endroits qui sont UTC+13 en hiver "1519380920
• testez toutes les bibliothèques et applications tierces et assurez-vous qu'elles traitent les données des fuseaux horaires correctement.
• tester les fuseaux horaires d'une demi-heure au moins.

• détaillé timezone tag page wiki sur Stack Overflow
• base de données Olson, alias Tz_database
• de l'IETF projet de procédures pour le maintien de l'Olson base de données
• Sources de fuseau Horaire et de l'heure d'été
• format ISO (ISO 8601)
• Mappage entre Olson et de base de données de fuseau Horaire Windows Id, de l'Unicode Consortium
• page fuseau horaire sur Wikipedia
• StackOverflow questions tagged dst
• StackOverflow questions tagged timezone
• Traitant de l'heure d'été - Microsoft DateTime meilleures pratiques
• Network Time Protocol on Wikipedia

autres:

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

Je ne suis pas sûr de ce que je peux ajouter aux réponses ci-dessus, mais voici quelques points de moi:

Types de temps

il y a quatre périodes différentes que vous devriez considérer:

1. heure de l'Événement: par exemple, le moment où un événement sportif international qui se passe, ou un couronnement/mort/etc. Cela dépend du fuseau horaire de l'événement et non pas de l'observateur.
2. Heure de la télévision: par exemple, une émission de télévision particulière est diffusé à 21 heures, heure locale, dans le monde entier. Important lorsque vous pensez à publier les résultats (de dire American Idol) sur votre site web
3. heure Relative: par exemple: cette question a une prime ouverte fermant dans 21 heures. C'est facile à afficher
4. heure récurrente: par exemple: une émission de télévision est tous les lundis à 21h, même lorsque L'heure D'été change.

Il ya aussi historique/alternate time. Ces sont ennuyeux parce qu'ils ne peuvent pas carte de retour à l'heure normale. Eg: dates juliennes, dates selon un calendrier lunaire sur Saturne, le calendrier Klingon.

stocker les horodateurs de début/fin dans UTC fonctionne bien. Pour 1, vous avez besoin d'un nom de fuseau horaire d'événement + offset stocké avec l'événement. Pour 2, vous avez besoin d'un identifiant de temps local stocké avec chaque région et d'un nom de fuseau horaire local + offset stocké pour chaque spectateur (il est possible de dériver cela de L'IP si vous êtes dans un crunch). Pour 3, stocker en UTC secondes et pas besoin pour les fuseaux horaires. 4 est un cas spécial de 1 ou 2 selon qu'il s'agit d'un événement global ou local, mais vous devez également stocker un créé à timestamp de sorte que vous pouvez dire si une définition de fuseau horaire a changé avant ou après que cet événement ait été créé. Cela est nécessaire si vous avez besoin d'afficher des données historiques.

temps de stockage

• Toujours stocker l'heure en UTC
• conversion à l'heure locale affichée (être local défini par l'utilisateur en regardant les données)
• lorsque vous stockez un fuseau horaire, vous avez besoin du nom, de l'horodatage et de l'offset. Cela est nécessaire parce que les gouvernements changent parfois la signification de leurs timezezones (par exemple: le gouvernement des États-Unis a changé les dates de DST), et votre application doit traiter les choses avec élégance... par exemple: le timestamp exact quand les épisodes de LOST ont montré à la fois avant et après les règles DST changé.

les Compensations et les noms

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

le match de finale de la Coupe du monde de football s'est produit en Afrique du Sud (UTC+2--SAST) le 11 juillet 2010 à 19:00 UTC.

avec cette information, nous pouvons historiquement déterminer l'heure exacte où la finale 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 le temps lorsqu'ils interrogent la base de données.

Système Temps

vous devez également garder votre OS, La base de données et l'application Fichiers tzdata en synchronisation, à la fois avec l'autre, et avec le reste du monde, et de tester largement lorsque vous mettez à niveau. Il n'est pas rare qu'une application tierce dont vous dépendez n'ait pas géré correctement un changement TZ.

assurez-vous que les horloges matérielles sont réglées sur UTC, et si vous utilisez des serveurs dans le monde entier, faites assurez-vous que leurs os sont configurés pour utiliser UTC. Cela devient évident lorsque vous devez copier des fichiers de log d'apache tournant toutes les heures à partir de serveurs 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 date maths dans votre tête lorsque vous ssh d'une boîte à l'autre et besoin de comparer des horodateurs.

aussi, Lancez ntpd sur toutes les boîtes.

Clients

Ne faites jamais confiance à l'horodatage que vous obtenez d'une machine client comme valide. Par exemple, la date: en-têtes HTTP, ou un appel javascript Date.getTime() . Ceux-ci sont très bien lorsqu'ils sont utilisés comme identificateurs opaques, ou lorsqu'ils font des calculs de date lors d'une seule session sur le même client, mais n'essayez pas de croiser ces valeurs avec quelque chose que vous avez sur le serveur. Vos clients n'exécutent pas NTP, et peuvent ne pas nécessairement avoir une batterie de travail pour leur horloge BIOS.

Trivia

enfin, les gouvernements vont parfois faire des choses très bizarres:

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'en 1937-06-30. Ce fuseau horaire ne peut pas être représenté exactement en utilisant le format HH: MM.

Ok, je pense que j'ai fini.

il s'agit d'une question importante et étonnamment difficile. La vérité est qu'il n'y a pas de norme entièrement satisfaisante pour la persistance du temps. Par exemple, la norme SQL et le format ISO (ISO 8601) ne suffisent manifestement pas.

du point de vue conceptuel, on traite habituellement de deux types de données de date-temps, et il est commode de les distinguer (les normes ci-dessus ne le font pas): " heure physique " et " heure civile ".

un instant "physique" du temps est un point dans la ligne de temps universelle continue que la physique traite (ignorant la relativité, bien sûr). Ce concept peut être correctement codé-persisté dans UTC, par exemple (si vous pouvez ignorer les secondes bissextiles).

Un "civil" le temps est un datetime spécification qui suit civile normes: un point de temps ici est complètement définie par un ensemble de champs de datetime (Y,M,D,H,MM,S,FS) en plus d'une TZ (fuseau de spécification) (aussi un" calendrier", en fait; mais supposons que nous limitons la discussion au calendrier grégorien). Un fuseau horaire et un calendrier permettent (en principe) de passer d'une représentation à l'autre. Mais les instants de temps civils et physiques sont des types fondamentalement différents de magnitudes, et ils doivent être maintenus conceptuellement séparés et traités différemment (une analogie: des tableaux d'octets et des chaînes de caractères).

la question est confuse parce que nous parlons de ces types d'événements de façon 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 futurs. Exemple (tiré de ma discussion ici .

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

maintenant, quand le jour viendra... au cas où ce rappel se déclencherait à

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, à moins que L'on sache ce que John voulait dire conceptuellement quand il a dit le calendrier "s'il vous plaît appelez-moi à 2019-Jul-27, 10:30:00 TZ=Chile/Santiago ".

voulait-il dire" date civile-heure" ("lorsque les horloges dans ma ville dire 10: 30")? Dans ce cas, A) est la bonne réponse.

ou voulait-il dire un "instant physique du temps", un point dans le continuus ligne du temps de notre univers, de dire, "quand la prochaine éclipse solaire arriver." Dans ce cas, la réponse B) est la bonne.

Un peu de Date/Heure Api obtenir cette distinction droite: parmi eux, Jodatime , qui est à la base de la prochaine (troisième!) Java DateTime API (JSR 310).

établir une séparation architecturale claire des préoccupations - pour savoir exactement quel niveau interagit avec les utilisateurs, et doit changer la date-heure pour/de la représentation canonique (UTC). Non-date-heure UTC est la présentation (suit utilisateurs de fuseau horaire local), heure UTC est le modèle (reste unique pour la fin et le milieu des gradins).

aussi, décidez quel est votre public réel, ce que vous n'avez pas à servir et où est-ce que vous dessinez la ligne . Ne touchez pas les calendriers exotiques à moins que vous ayez réellement des clients importants là-bas et puis considérer le(s) serveur (s) séparé (s) face à l'utilisateur juste pour cette région.

si vous pouvez acquérir et maintenir l'emplacement de l'utilisateur, utilisez l'emplacement pour la conversion systématique date-heure (par exemple la culture.net ou une table SQL) mais fournir un moyen pour l'utilisateur final de choisir des dérogations si date-heure est critique pour vos utilisateurs.

S'il y a vérification historique obligations impliqué (comme dire exactement quand Jo in az a payé une facture Il ya 2 ans en septembre) puis garder à la fois UTC et l'heure locale pour l'enregistrement (vos tables de conversion va changer dans un cours du temps).

définir le fuseau horaire de référence pour les données qui viennent en vrac - comme des fichiers, des services web, etc. Disons que la compagnie de la côte Est a un centre de données en CA - vous devez demander et savoir ce qu'ils utilisent comme norme à la place d'autant que l'un ou l'autre.

Ne faites pas confiance à votre fuseau horaire décalages incorporés dans la représentation textuelle de la date-heure et ne pas accepter de les analyser et de les suivre. demandent toujours que le fuseau horaire et/ou le fuseau de référence soient explicitement définis . Vous pouvez facilement recevoir l'heure avec PST offset mais l'heure est en fait EST puisque c'est l'Heure de référence du client et les enregistrements ont été juste exportés à un serveur qui est en PST.

vous devez savoir à propos de L'Olson base de données tz , qui est disponible à partir 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 dans le moment (et l'opportunité) de passer de l'heure d'hiver à l'heure d'été (Standard et avancée) dans différents pays du monde. En 2009, la dernière sortie a été 2009s; en 2010, c'était 2010n; en 2011, c'était 2011n; à la fin de mai 2012, la sortie était 2012c. Notez qu'il y a un ensemble de code pour gérer les données et les données de fuseau horaire proprement dites, dans deux archives distinctes (tzcode20xxy.tar.gz et tzdata20xxy.tar.gz). Le code et les données sont du 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 avez besoin de garder une trace de différentes zones, puis vous avez besoin de la base de données Olson. Comme d'autres l'ont conseillé, vous voulez également stocker les données dans un format fixe - UTC est normalement celui choisi - avec un enregistrement du fuseau horaire dans lequel les données ont été générées. Vous pouvez faire une distinction entre le décalage de UTC à l'heure et le nom du fuseau horaire; cela peut faire une différence plus tard. De plus, savoir qu'il est actuellement 2010-03-28T23: 47:00-07: 00 (É. - U./Pacifique) peut ou ne peut pas vous aider à interpréter la valeur 2010-11-15T12: 30 - ce qui est probablement spécifié dans la TVP (heure normale du Pacifique) plutôt que PDT (heure avancée du Pacifique).

les interfaces standard de la bibliothèque C ne sont pas très utiles pour ce genre de choses.

Le Olson données a été déplacé, en partie parce que D Olson sera bientôt à la retraite, et en partie parce qu'il y avait une (maintenant rejeté) action en justice contre les responsables de violation des droits d'auteur. Fuseau la base de données est maintenant gérée sous les auspices de IANA , L'Autorité des numéros attribués sur L'Internet, et il y a un lien sur la page d'accueil à "base de données des fuseaux horaires . La liste de discussion est maintenant tz@iana.org ; la liste d'annonce est tz-announce@iana.org .

en général, inclut le décalage horaire local (y compris le décalage DST) dans les horodateurs stockés: UTC seul n'est pas suffisant si vous voulez plus tard afficher l'horodateur dans son fuseau horaire d'origine (et le réglage DST).

gardez à l'esprit que le décalage n'est pas toujours un nombre entier d'heures (par exemple, L'heure standard Indienne est UTC+05:30).

par exemple, les formats appropriés sont un tuple (unix time, offset en minutes) ou ISO 8601 .

traverser la frontière du "temps informatique" et du "temps des gens" est un cauchemar. Le principal étant qu'il n'y a aucune sorte de norme pour les règles régissant les fuseaux horaires et l'heure d'été. Les pays sont libres de changer leur fuseau horaire et les règles de L'heure avancée à tout moment, et ils le font.

certains pays, comme Israël et le Brésil, décident chaque année de l'heure d'été, de sorte qu'il est impossible de savoir à l'avance quand l'heure d'hiver sera en vigueur. D'autres ont fixe (ish) les règles relatives au moment où la TVD est en vigueur. Les autres pays n'utilisent pas la DST comme tous les autres pays.

les fuseaux horaires n'ont pas à être des différences D'heure par rapport au GMT. Le népal est +5.45. Il y a même des fuseaux horaires qui sont +13. Cela signifie que:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

sont tous à la même heure, mais 3 jours différents!

il n'y a pas non plus de norme claire sur les abréviations pour les fuseaux horaires, et comment ils changent quand à DST donc vous finissez avec des choses comme ceci:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

le meilleur conseil est de rester loin des heures locales autant que possible et de coller à UTC où vous le pouvez. Convertissez - vous en heure locale au dernier moment possible.

lors des tests, assurez-vous de tester les pays de l'hémisphère occidental et de l'hémisphère oriental, avec L'heure D'été en cours et pas et un pays qui n'utilise pas l'heure d'hiver (6 au total).

pour PHP:

la classe DateTimeZone en PHP > 5.2 est déjà basée sur le Olson DB que d'autres mentionnent, donc si vous faites des conversions de fuseau horaire en PHP et non dans le DB, vous êtes exempté de travailler avec (les fichiers Olson difficiles à comprendre).

cependant, PHP N'est pas mis à jour aussi souvent que la base de données Olson, donc simplement en utilisant PHPs time zone conversions peut vous laisser avec des informations DST obsolètes, et influencer l'exactitude de vos données. Bien que cela ne devrait pas se produire fréquemment, cela peut se produire, et va se produire si vous avez une large base d'utilisateurs dans le monde entier.

pour faire face au problème ci-dessus, utilisez le paquet timezonedb pecl , dont la fonction est de mettre à jour les données du fuseau horaire de PHP. Installez ce paquet aussi souvent qu'il est mis à jour. (Je ne suis pas sûr que ces paquets mettent à jour suivent exactement les mises à jour D'Olson, mais il semble qu'ils soient mis à jour sur une fréquence qui est au moins très proche des mises à jour D'Olson.)

si votre conception peut l'accommoder, éviter la conversion de l'heure locale tous ensemble!

je sais à certains que cela pourrait sembler insensé, mais pensez à UX: utilisateurs traitement proche, dates relatives (aujourd'hui, hier, lundi prochain) plus rapide que les dates absolues (2010.09.17, vendredi 17 septembre) en coup d'oeil. Et quand vous y pensez plus, la précision des fuseaux horaires (et DST) est plus importante, plus la date est proche de now() , donc si vous pouvez exprimer dates / datetimes dans un format relatif pour +/- 1 ou 2 semaines, le reste des dates peuvent être UTC et il ne sera pas trop important à 95% des utilisateurs.

de cette façon, vous pouvez stocker toutes les dates dans UTC et faire les comparaisons relatives dans UTC et simplement afficher les dates UTC de l'utilisateur en dehors de votre seuil de Date Relative.

cela peut aussi s'appliquer à l'entrée de l'utilisateur (mais généralement d'une manière plus limitée). Sélection à partir d'une liste déroulante qui n'a que { Hier, aujourd'Hui, Demain, Lundi prochain, jeudi Prochain } est tellement plus simple et plus facile pour l'utilisateur qu'un sélecteur de date. Les cueilleurs de dattes sont parmi les composantes les plus douloureuses du remplissage de formulaires. Bien sûr, cela ne fonctionnera pas pour tous les cas, mais vous pouvez voir qu'il suffit d'un peu de design intelligent, il est très puissant.

bien que je ne l'ai pas encore essayé, une approche aux ajustements de fuseaux horaires que je trouverais convaincante serait la suivante:

1. tout stocker dans UTC.

2. créer un tableau TZOffsets avec trois colonnes: RegionClassId, StartDateTime, et OffsetMinutes (int, en minutes).

dans le tableau, conservez une liste de dates et d'heures quand l'heure locale changé, et de combien. Le nombre de régions dans le tableau et le nombre de dates dépendent des dates et les régions du monde vous avez besoin de soutien. Pensez à cela comme si c'est "historique", même si les dates devraient inclure l'avenir de certains de limite pratique.

quand vous avez besoin de calculer l'heure locale de n'importe quelle heure UTC, faites juste ceci:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

vous pourriez vouloir mettre cette table en cache dans votre application et utiliser LINQ ou un moyen similaire pour faire les requêtes plutôt que de frapper la base de données.

ces données peuvent être extraites de la public domain TZ database .

avantages et notes de bas de page de cette approche:

1. aucune règle n'est entrée dans le code, vous pouvez ajuster les offsets pour de nouvelles régions ou plages de dates facilement.
2. vous ne devez pas prendre en charge toutes les dates ou régions, vous pouvez ajouter en fonction des besoins.
3. régions n'ont pas à correspondre directement aux frontières géopolitiques, et pour éviter la duplication des lignes (par exemple, la plupart des États aux États-Unis traitent DST de la même manière), vous pouvez avoir des entrées de grande classe de région qui lient dans un autre tableau à des listes plus traditionnelles d'états, de pays, etc.
4. pour des situations comme les États-Unis où la date de début et de fin de L'heure D'été a changé au cours des dernières années, c'est assez facile à gérer.
5. étant donné que le champ StartDateTime peut également stocker une heure, le temps de changement standard de 2:00 AM est manipulé facilement.
6. pas partout dans le monde utilise un DST d'une heure. Cela traite ces cas facilement.
7. la table de données est multi-plateforme et pourrait être un projet open-source séparé qui pourrait être utilisé par les développeurs qui utilisent presque n'importe quelle plate-forme de base de données ou le langage de programmation.
8. peut être utilisé pour les compensations qui ont rien à voir avec les fuseaux horaires. Par exemple, les ajustements d'une seconde qui se produisent de temps en temps pour s'ajuster à la rotation de la terre, les ajustements historiques à et dans le calendrier grégorien, etc.
9. Puisqu'il s'agit d'une table de base de données, de requêtes de rapport standard, etc. peut profiter des données sans avoir à passer par le code logique de l'entreprise.
10. cela traite les décalages de fuseau horaire aussi bien si vous le voulez, et peut même tenir compte de l'historique spécial cas où une région est assignée à un autre fuseau horaire. Tout ce dont vous avez besoin est une date initiale qui attribue un décalage horaire à chaque région avec une date de début minimale. Cela nécessiterait la création d'au moins une région pour chaque fuseau horaire, mais vous permettrait de poser des questions intéressantes comme: "Quelle est la différence d'heure locale entre Yuma, Arizona et Seattle, Washington le 2 février 1989 à 5h00 du matin?"(Juste soustraire une SOMME() de l'autre).

maintenant, le seul l'inconvénient de cette approche ou tout autre est que les conversions de heure locale à GMT ne sont pas parfaites, car tout changement de DST qui a un décalage négatif à l'horloge répète une heure locale donnée. Ce n'est pas une façon facile de gérer ça, j'en ai peur, ce qui est une des raisons pour lesquelles stocker le local times est une mauvaise nouvelle en premier lieu.

j'ai choisi deux types de systèmes, "systèmes de planification du travail posté (par exemple, ouvriers d'usine)" et "systèmes de gestion dépendant du gaz

les journées de 23 et 25 heures sont pénibles, de même que les quarts de 8 heures qui prennent 7 ou 9 heures. Le problème est que vous trouverez que chaque client, ou même département du client ont des règles différentes qu'ils ont créé (souvent sans documenter) sur ce qu'ils font dans ces cas spéciaux.

quelques questions sont il est préférable de ne pas demander au client avant qu'il ait payé pour votre logiciel "prêt à l'emploi". Il est très rare de trouver un client qui pense à ce type de problème dès le départ lors de l'achat d'un logiciel.

je pense que dans tous les cas vous devriez enregistrer L'heure dans UTC et convertir à/de l'heure locale avant de stocker la date/heure. Cependant même savoir qui prennent un temps donné peut être dur avec l'heure d'été et les fuseaux horaires.

j'ai récemment eu un problème dans une application web où sur un Ajax post-back le datetime revenir à mon code côté serveur était différent du datetime servi.

il a très probablement eu à voir avec mon code JavaScript sur le client qui a construit la date pour afficher à nouveau au client comme chaîne de caractères, parce que JavaScript s'ajustait pour fuseau horaire et l'heure d'été, et dans certains navigateurs le calcul pour quand appliquer l'heure d'été semble être différent que dans d'autres.

à la fin, j'ai choisi de supprimer entièrement les calculs de date et d'heure sur le client, et j'ai posté de nouveau sur mon serveur sur une clé entière qui a ensuite été traduite à l'Heure de date sur le serveur, pour permettre des transformations cohérentes.

ce que J'ai appris: N'utilisez pas les calculs de date et d'heure JavaScript dans les applications web à moins que vous ne le deviez absolument.

pour le web, les règles ne sont pas si compliquées...

• Côté Serveur, utiliser UTC
• côté Client, utilisez Olson
  • Raison: UTC-décalages ne sont pas la lumière du jour d'épargne-sûr (par exemple, New York est (UTC - 5 Heures) une partie de l'année, HNE (UTC - 4 Heures) reste de l'année).
  • pour la détermination du fuseau horaire côté client, vous avez deux options:
    • 1) l'utilisateur ensemble de la zone (Safer)
      • ressources: prêt pour le Web Olson tz HTML Dropdown et JSON
    • 2) zone de détection automatique
      • ressource: jsTimezoneDetect

le reste est juste UTC/conversion locale en utilisant vos bibliothèques datetime côté serveur. Bon pour aller...

quand il s'agit d'applications qui tournent sur un serveur , y compris les sites web et d'autres services back-end, le réglage du fuseau horaire du serveur doit être ignoré par l'application.

le conseil commun est de définir le fuseau horaire du serveur à UTC. Il s'agit en effet d'une bonne pratique exemplaire, mais elle existe en tant que pansement pour les demandes qui ne suivent pas d'autres pratiques exemplaires. Par exemple, un service peut écrire pour enregistrer des fichiers avec local les horodateurs au lieu des horodateurs basés sur UTC, créant ainsi des ambiguïtés lors de la transition de retour à l'heure avancée. Définir le fuseau horaire du serveur à UTC corrigera que application. Cependant, la vraie solution serait que L'application se connecte en utilisant UTC pour commencer.

code côté serveur, y compris les sites web, devrait jamais s'attendre à ce que le fuseau horaire local du serveur soit quelque chose en particulier.

dans certaines langues, le fuseau horaire local peut facilement se glisser dans le code d'application. Par exemple, la méthode DateTime.ToUniversalTime dans .NET convertira de en UTC, et la propriété DateTime.Now retournera l'heure courante dans le fuseau horaire local. De plus, le constructeur Date en JavaScript utilise le fuseau horaire local de l'ordinateur. Il existe de nombreux autres exemples de ce genre. Il est important de pratiquer la programmation défensive, en évitant tout code qui utilise le fuseau horaire local de l'ordinateur.

réserver en utilisant le fuseau horaire local pour le code côté client, tels que les applications de bureau, les applications mobiles, et le JavaScript côté client.

gardez vos serveurs sur UTC, et assurez-vous qu'ils sont tous configurés pour ntp ou l'équivalent.

UTC évite les problèmes d'heure avancée, et les serveurs non synchronisés peuvent causer des résultats imprévisibles qui prennent un certain temps à diagnostiquer.

soyez prudent lorsque vous utilisez des horodateurs stockés dans le système de fichiers FAT32 - il est toujours persisté dans les coordonnées locales (qui comprennent DST - voir article msdn ). Obtenu brûlé.

une autre chose, assurez-vous que les serveurs ont le patch de jour mis à jour appliqué.

l'an dernier, nous avons été confrontés à une situation où notre temps était constamment dépassé d'une heure pendant une période de trois semaines pour les utilisateurs Nord-Américains, même si nous utilisions un système basé sur UTC.

il s'avère à la fin que c'était les serveurs. Ils avaient juste besoin d'un correctif à jour appliqué ( Windows Server 2003 ).

PHP DateTimeZone::listAbbreviations() sortie

cette méthode PHP renvoie un tableau associatif contenant quelques temps 'majeurs' (comme CEST), qui contiennent eux-mêmes des temps 'géographiques' plus spécifiques (comme Europe/Amsterdam).

si vous utilisez ces fuseaux horaires et leurs informations offset / DST, il est extrêmement important de réaliser ce qui suit:

Il semble que tous les différentes configurations offset/DST (incluant les configurations historiques) de chaque fuseau horaire sont incluses!

par exemple, Europe/Amsterdam peut être trouvé six fois dans la sortie de cette fonction. Deux occurrences (offset 1172/4772) correspondent au temps D'Amsterdam utilisé jusqu'en 1937, deux (1200/4800) au temps utilisé entre 1937 et 1940 et deux (3600/4800) au temps utilisé depuis 1940.

Par conséquent, vous ne pouvez pas compter sur les informations offset/DST retournées par cette fonction comme étant actuellement correcte/en cours d'utilisation!

si vous voulez connaître l'offset/DST actuel d'un certain fuseau horaire, vous devez faire quelque chose comme ceci:

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

si vous maintenez des systèmes de bases de données qui fonctionnent avec DST active, vérifiez soigneusement s'ils doivent être arrêtés pendant la transition en automne. Mandy DBS (ou d'autres systèmes aussi) n'aime pas passer le même point à l'heure (locale) deux fois, ce qui est exactement ce qui se passe lorsque vous retournez le temps à l'automne. SAP a résolu ce problème avec une solution (IMHO really neat) - au lieu de retourner l'horloge, ils ont juste laissé l'horloge interne fonctionner à la moitié de la vitesse habituelle pendant deux heure...

règles d'Entreprise doit toujours travailler sur temps civil (sauf si il y a une législation qui dit le contraire). Sachez que le temps civil est un gâchis, mais c'est ce que les gens utilisent donc c'est ce qui est important.

à L'intérieur, gardez les horodateurs dans quelque chose comme civil-time-seconds-from-epoch. Le epoch n'a pas d'importance particulière (je suis pour le Unix epoch ) mais il rend les choses plus faciles que l'alternative. Prétendez que leap-seconds n'existe pas à moins que vous ne fassiez quelque chose que vraiment a besoin d'eux (par exemple, la localisation par satellite). La mise en correspondance entre les horodateurs et l'heure affichée est le seul point où les règles DST doivent être appliquées; les règles changent fréquemment (au niveau mondial, plusieurs fois par an; blâmer les politiciens) de sorte que vous devez vous assurer que vous ne durcissez pas la mise en correspondance. Base de données TZ d'Olson est inestimable.

utilisez-vous le .net framework ? Si c'est le cas, permettez-moi de vous présenter le type DateTimeOffset , ajouté avec .NET 3.5.

cette structure contient à la fois un DateTime et un décalage ( TimeSpan ), qui spécifie la différence entre la date et l'Heure de l'instance DateTimeOffset et le temps universel coordonné (UTC).

• la méthode statique DateTimeOffset.Now permet retourner un DateTimeOffset instance constituée de l'heure courante (locale) et du décalage local (tel que défini dans les informations régionales du système d'exploitation).

• la méthode statique DateTimeOffset.UtcNow retournera a DateTimeOffset instance consistant en L'heure courante en TUC (as si vous étiez à Greenwich).

D'autres types utiles sont les TimeZone et TimeZoneInfo des classes.

pour ceux qui luttent avec ce sur .NET , voir si l'utilisation de DateTimeOffset et/ou TimeZoneInfo valent la peine de votre temps.

si vous souhaitez utiliser IANA/Olson time zones , ou trouver les types intégrés sont insuffisants pour vos besoins, consultez Heure de Noda , qui offre une API de date et d'heure beaucoup plus intelligente pour .NET.

je voulais juste souligner deux choses qui semblent inexactes ou au moins déroutantes:

persistent toujours le temps selon une norme unifiée qui n'est pas touchés par la lumière du jour d'épargne. GMT et UTC ont été mentionnés par personnes différentes, bien que UTC semble être mentionné le plus souvent.

Pour (presque) toutes les pratiques de l'informatique fins, l'UTC est, en fait, à l'heure GMT. Sauf si vous voyez un horodatage avec une fraction de seconde, vous avez affaire à GMT, ce qui rend cette distinction superflue.

inclure l'heure locale décalée telle quelle (y compris l'heure d'été décalée) lorsque: stockage des horodateurs.

un timestamp est toujours représenté en GMT et n'a donc pas de décalage.

Voici mon expérience: -

(ne nécessite pas de bibliothèque tierce)

• côté serveur, stockez les temps au format UTC de sorte que toutes les valeurs date/heure dans la base de données sont dans un seul standard quel que soit l'emplacement des utilisateurs, serveurs, fuseaux horaires ou DST.
• sur la couche UI ou dans les e-mails envoyés à l'utilisateur, vous devez afficher les heures en fonction de l'utilisateur. Pour cette question, vous devez avoir de l'utilisateur timezone offset de sorte que vous pouvez ajouter cette offset à la valeur UTC de votre base de données qui résultera en temps local de l'utilisateur. Vous pouvez soit prendre le décalage du fuseau horaire de l'utilisateur lorsqu'il s'inscrit ou vous pouvez les détecter automatiquement sur les plateformes web et Mobiles. Pour les sites Web, la méthode Gettimezoneoffset() de la fonction JavaScript est une norme depuis la version 1.0 et compatible avec tous les navigateurs. (Réf: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )

Tom Scott vidéo sur les fuseaux horaires sur YouTube sur le Computerphile canal dispose également d'un agréable et divertissant description du sujet. Exemples:

• Samoa (une île de l'océan Pacifique) reportant son fuseau horaire de 24 heures pour faciliter le commerce avec L'Australie et la Nouvelle-Zélande,
• cisjordanie , où 2 les populations de personnes sont à la suite des fuseaux horaires différents,
• 18ème siècle passe du calendrier Julien au calendrier grégorien calendrier (qui s'est produit au XXe siècle en Russie).

en fait, kernel32.dll n'exporte pas SystemTimeToTzSpecificLocation. Il exporte cependant les deux suivants: SystemTimeToTzSpecificLocalTime et TzSpecificLocalTimeToSystemTime...

juste un exemple pour prouver que gérer le temps est l'énorme gâchis décrit, et que vous ne pouvez jamais être complaisant. Dans plusieurs endroits sur cette page leap-seconds ont été ignorés.

il y a plusieurs années, le système D'exploitation Android utilisait les satellites GPS pour obtenir une référence de temps UTC, mais ignorait le fait que les satellites GPS n'utilisent pas les secondes intercalaires. Personne n'a remarqué jusqu'à ce qu'il y ait confusion la veille du Nouvel An, quand les utilisateurs de téléphone Apple et Android ont fait leur compte à rebours à 15 secondes d'intervalle.

je pense qu'il a été depuis corrigé, mais vous ne savez jamais quand ces 'petits détails' reviendront vous hanter.

Ne jamais compter uniquement sur des constructeurs comme

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

ils peuvent jeter des exceptions quand une certaine date heure n'existe pas en raison de DST. Au lieu de cela, construisez vos propres méthodes pour créer de telles dates. Dans ceux-ci, attraper toutes les exceptions qui se produisent en raison de DST, et ajuster le temps est nécessaire avec le décalage de transition. L'heure D'été peut survenir à des dates différentes et à des heures différentes (même à minuit pour le Brésil) selon le fuseau horaire.

• jamais, Jamais magasin, heure locale, sans décalage UTC (ou une référence à la zone de temps)-des exemples de la façon de ne pas le faire inclure FAT32 et struct tm dans C. 1
• Comprendre qu'un fuseau horaire est une combinaison de
  • un ensemble de décalages horaires (par exemple, +0100 en hiver, +0200 en été)
  • les règles relatives au passage au numérique (qui peut changer au fil du temps: par exemple, dans les années 90, L'UE a harmonisé le passage au numérique en tant que les derniers dimanches de Mars et d'octobre, à 2 heures, heure normale / 3 heures HNR; auparavant, cette situation différait d'un État membre à l'autre).

1 certaines implémentations de struct tm stockent l'offset UTC, mais cela n'en fait pas la norme.

en traitant avec les bases de données (en particulier MySQL , mais cela s'applique à la plupart des bases de données), j'ai trouvé difficile de stocker UTC.

• les bases de données fonctionnent généralement avec le serveur datetime par défaut (C'est-à-dire CURRENT_TIMESTAMP).
• vous ne pouvez pas changer le fuseau horaire du serveur.
• même si vous êtes capable de changer le fuseau horaire, vous pouvez avoir du code tiers qui s'attend à ce que le fuseau horaire du serveur soit local.

j'ai trouvé plus facile de simplement stocker le datetime du serveur dans la base de données, puis laisser la base de données convertir le datetime stocké en UTC (C'est-à-dire UNIX_TIMESTAMP()) dans les instructions SQL. Après cela, vous pouvez utiliser le datetime comme UTC dans votre code.

si vous avez 100% de contrôle sur le serveur et tout le code, il est probablement préférable de changer le fuseau horaire du serveur en UTC.