Gérer les fuseaux horaires dans le stockage ?

StackOverflow https://stackoverflow.com/questions/11975

Question

Tout stocker en GMT ?

Stocker tout tel qu'il a été saisi avec un décalage intégré ?

Faites le calcul à chaque fois que vous effectuez un rendu ?

Afficher les heures relatives « il y a 1 minutes » ?

Était-ce utile?

La solution

Vous devez stocker en UTC - si vous ne le faites pas, vos rapports historiques et votre comportement pendant des événements comme l'heure d'été disparaissent...drôle.GMT est une heure locale, soumise à l'heure d'été par rapport à UTC (ce qui ne l'est pas).

La présentation aux utilisateurs dans différents fuseaux horaires peut être un véritable salaud si vous stockez l'heure locale.Il est facile de s'adapter au local si vos données brutes sont en UTC : ajoutez simplement le décalage de votre utilisateur et le tour est joué !

Joel en a parlé dans l'un des podcasts (de manière détournée) - il a dit à stockez vos données dans la plus haute résolution possible (recherchez « fidélité »), car vous pouvez toujours le mutiler lorsqu'il s'éteint à nouveau.C'est pourquoi je dis de le stocker au format UTC, car l'heure locale, vous devez l'ajuster pour toute personne qui n'est pas dans ce fuseau horaire, et cela demande beaucoup de travail.Et vous devez savoir si, par exemple, l'heure d'été était en vigueur lorsque vous avez enregistré l'heure.Beurk.

Souvent, dans le passé, dans les bases de données, j'en ai stocké deux : UTC pour le tri, heure locale pour l'affichage.De cette façon, ni l'utilisateur ni l'ordinateur ne sont confus.

Maintenant, pour afficher :Bien sûr, vous pouvez faire la chose "il y a 3 minutes", mais seulement si vous stockez UTC - sinon, les données saisies dans différents fuseaux horaires feront des choses comme s'afficher comme "il y a -4 heures", ce qui fera paniquer les gens.Si vous souhaitez afficher une heure réelle, les gens adorent l'avoir à leur heure locale - et si les données sont saisies dans plusieurs fuseaux horaires, vous ne pouvez le faire facilement que si vous stockez UTC.

Autres conseils

La réponse, comme toujours, est « cela dépend ».

Cela dépend de ce que vous décrivez avec l'heure et de la manière dont les données vous ont été fournies.La clé pour décider comment stocker les valeurs temporelles est de décider si vous perdez des informations en supprimant le fuseau horaire, et de ne pas surprendre vos utilisateurs.

Il y a des avantages certains à stocker des données dans un time_t UTC - il s'agit d'un seul entier, permettant un tri rapide et un stockage facile.

Je vois le problème comme étant décomposé en domaines spécifiques :

  1. Données historiques
  2. Données futures à court terme
  3. Données futures et à long terme

Avec les sous-classes suivantes sur chacune :

  1. Système fourni
  2. Fourni par l'utilisateur

Regardons-les un à la fois.

Système fourni:Je recommanderais d'exécuter des systèmes en UTC, vous éviterez alors le problème de fuseau horaire et encore une fois, aucune perte d'informations n'est constatée (c'est toujours UTC).

Données historiques:Il s'agit d'éléments tels que les fichiers journaux du système, les statistiques de processus, le traçage, les dates/heures des commentaires, etc.Les données ne changeront pas et le descripteur de fuseau horaire ne changera pas rétroactivement.Pour ce type de données, aucune information n'est perdue en stockant les informations en UTC quel que soit le fuseau horaire dans lequel elles ont été fournies.Alors, supprimez le fuseau horaire.

Données futures et à long terme:Ce sont des événements qui se situent assez loin dans le futur ou qui continueront de se produire.S’ils sont conservés suffisamment longtemps, les descripteurs de fuseau horaire sont assurés de changer.Un bon exemple de ce type de données est « La réunion hebdomadaire de gestion ».Il s’agit de données qui sont saisies une seule fois et qui devraient continuer à fonctionner à perpétuité.Pour ces valeurs, il est important de déterminer si elles sont fournies par le système ou par l'utilisateur.Pour les données fournies par l'utilisateur, l'heure doit être stockée avec le fuseau horaire du créateur, tout le reste entraîne une perte d'informations.Cette perte d'informations devient apparente lorsque la définition du fuseau horaire change et que l'heure est affichée au créateur comme ayant une valeur totalement différente !

Comme Bwooce l'a indiqué, il existe une certaine confusion lorsque le créateur et le spectateur se trouvent dans des fuseaux horaires différents.Dans ce cas, je m'attendrais à ce que l'application indique quelles valeurs de temps ont été déplacées en raison d'un décalage horaire par rapport à leurs emplacements précédents.

Données futures à court terme:Il s’agit de données qui vont rapidement devenir historiques, ou qui ne sont valables que pour une courte période.Des exemples pourraient être des minuteries à intervalles, des transitions de notation, etc.Pour ces données, étant donné qu’il est peu probable que la définition change entre la création de la valeur et le moment où elle devient historique, il pourrait être possible de s’en sortir en supprimant le fuseau horaire.Cependant, j'ai constaté que ces valeurs ont la mauvaise habitude de devenir des « données futures à long terme ».

Une fois que vous avez décidé de stocker le fuseau horaire, il faut faire attention à la manière dont il est stocké.

  • Ne stockez pas le fuseau horaire sous forme de décalage ou de descripteur complet.

Si vous stockez un fuseau horaire sous forme de décalage, que faites-vous si le fuseau horaire change ?Parcourez-vous le système et effectuez-vous une modification globale des données existantes ?Si vous le faites, vous avez désormais rendu les valeurs historiques incorrectes.De bons exemples de cette erreur sont Oracle et iCal.Oracle stocke les informations de fuseau horaire sous forme de décalage par rapport à UTC et iCal inclut le descripteur complet du fuseau horaire de création.

  • Stockez-le comme nom.

Cela permet de changer la définition du fuseau horaire sans avoir à modifier les valeurs existantes dont vous disposez.Cela rend le tri plus difficile, car tout index généré peut être invalide si les données de fuseau horaire changent.

Si les développeurs continuent de tout stocker en UTC, quel que soit le fuseau horaire, nous continuerons à voir les problèmes que nous avons constatés avec le dernier lot de changements de fuseau horaire.

Dans une organisation, les secrétaires devaient imprimer les calendriers de leurs équipes avant le passage à l'heure d'été, puis les réimprimer après le changement.Finalement, ils ont comparé les deux et ont recréé tous les rendez-vous déplacés.Bien sûr, ils en ont manqué plusieurs, et il y a eu plusieurs semaines de douleur jusqu'à ce que l'ancienne date d'heure d'été soit atteinte et que les heures redeviennent correctes.

Josh a tout à fait raison ci-dessus, mais j'ai une subtile mise en garde à expliquer.Il s'agit d'un cas sans réponse correcte concernant les événements et les fuseaux horaires futurs.

Prenons le cas d'un rendez-vous répété.Cela se produit à GMT 0000 (pour plus de simplicité), soit 1200 NZST (heure normale de Nouvelle-Zélande) et 1000 AEST à Sydney en Australie.

Lorsque l’heure d’été entre en vigueur dans une zone, que doit-il arriver au rendez-vous ?Devrait-il:

1a.Si le changement TZ se trouve dans la zone du "propriétaire" du rendez-vous (qui l'a réservé), essayez de rester au même moment de l'horloge de bureau (par exemple 10h00)?
1b.Si le changement TZ se trouve dans l'une des autres zones du participant à la réunion, alors pas de changement

Conséquences:Il évolue pour tout le monde, de façon inattendue, en raison du changement TZ des propriétaires, mais il reste "la réunion de 10h" en ce qui concerne le propriétaire.

'2.Comme ci-dessus, mais inversé.

Conséquences:Cela bouge pour le propriétaire de la réunion (la réunion de 10h devient la réunion de 9h, ou v/v), ce qui peut être attendu mais peu pratique.Il reste à la même heure de bureau pour les autres participants jusqu'à ce qu'ils effectuent leur propre transition TZ.

Ni l’un ni l’autre n’est parfait.Prenons le cas de deux rendez-vous, l'un réservé par la personne A à 10 heures du matin, heure locale, l'autre réservé par la personne B avec la personne A comme participant à 9 heures du matin.Si la personne A et la personne B se trouvent dans des zones géographiques différentes, un changement d'heure d'été pourrait facilement entraîner une double réservation.

Si votre esprit est un peu penché à ce stade, je comprends tout à fait.

Le point derrière cet exemple est que pour appliquer correctement l'un ou l'autre de ces comportements, vous devez connaître non seulement la version UTC de l'heure locale, mais également le TZ (et non le décalage) dans lequel se trouvait le propriétaire lorsqu'il l'a réservé.Sinon vous n'avez pas d'autre choix que de prendre l'option 2, en silence, sans même informer qui que ce soit que les choses ont changé depuis GMT, les horaires ne changent pas et seule la présentation change... non ?(non, c'est ça le piège, la présentation compte quand votre rendez-vous de 10h avance tout seul)

Je dois remercier mon collègue et ami Jason Pollock pour cette idée.Lire son point de vue ici, et le suivi discutant iCal et VTIMEZONE ici.

Tout stocker en GMT/UTC me semble le plus logique.Vous pouvez ensuite afficher la date et l'heure dans chaque fuseau horaire de votre choix.

Quelques réserves :

  1. Si un temps n'est spécifié que comme un temps d'horloge mural et que c'est la représentation principale, ce n'est pas un temps absolument spécifié.Vous devez (et ne pouvez pas) le convertir dans une représentation GMT.PAR EXEMPLE.9h00 tous les matins.Autrement dit:ce n'est pas une heure (date).
  2. Si vous enregistrez une date et une heure d'un futur rendez-vous, vous devez utiliser le décalage pour GMT spécifié par le fuseau horaire d'entrée et le le moment dans le temps lui-même.Donc, s'il s'agit d'un rendez-vous en été fait en hiver en par exempleL'Europe occidentale, c'est +2: 00, bien que le décalage normal (heure hivernale) soit +1: 00.Cela résoudra le problème du calendrier que Bwooce a mentionné.
  3. Bien sûr, la même chose qui s'applique à l'utilisation du décalage droit lors de la conversion en GMT s'applique lors de la conversion à une date et une heure dans un fuseau horaire particulier.

Heureusement, lorsqu'il est utilisé correctement, le type DateTime (.NET) prend en charge tous les détails sanglants liés à la tenue des calendriers, etc.pour vous et tout cela devrait être très simple quand vous savez comment cela fonctionne.

Personnellement, je ne vois aucune raison de ne pas tout stocker en GMT, puis d'utiliser le fuseau horaire local des utilisateurs pour afficher l'heure qui les concerne.

Si vous souhaitez afficher l'heure relative, vous avez évidemment toujours besoin de l'heure et d'effectuer une traduction, mais si vous souhaitez effectuer la traduction, je pense que GMT est toujours votre meilleure option.

J'ai donc fait une petite expérience avec le serveur MSSQL.

J'ai créé un tableau et ajouté une ligne avec le fuseau horaire localisé actuel (Australie).Ensuite, j'ai changé ma date/heure pour qu'elle soit GMT et j'ai ajouté une autre ligne.

Même si ces lignes ont été ajoutées à environ 10 secondes d'intervalle, elles apparaissent dans le serveur SQL comme si elles étaient espacées de 10 heures.

À tout le moins, cela me dit au moins que je devrais stocker les dates de manière cohérente, ce qui pour moi ajoute du poids à l'argument en faveur de leur stockage au format GMT.

MS Dynamics stocke GMT et connaît ensuite, au niveau de l'utilisateur, votre fuseau horaire par rapport à GMT.Ensuite, il vous affiche les éléments dans votre fuseau horaire.

Je pensais juste que je lancerais cela car c'est un groupe assez important chez MS et c'est ainsi qu'ils ont décidé de le gérer.

je préfère tout stocker avec le fuseau horaire.le client peut décider de quelle manière il doit être présenté plus tard.ma bibliothèque préférée pour la conversion est la Base de données PostgreSQL.

Jetez un œil ici, le w3c a fait un excellent travail en répondant à la question.

Regardez les cas d'utilisation.

http://www.w3.org/TR/timezone/

Notez qu'ils recommandent de stocker les dates et heures au format UTC et non GMT, GMT étant soumis à l'heure d'été.

J'aime stocker en GMT et afficher uniquement les valeurs relatives ("il y a environ 10 secondes", "il y a 5 mois").Les utilisateurs n'ont pas besoin de voir les horodatages réels pour la plupart des cas d'utilisation.

Il existe certainement des exceptions, et une candidature individuelle peut en comporter plusieurs, il ne peut donc pas s'agir d'une réponse « à sens unique ».Les choses qui nécessitent une forte capacité d'audit (par ex.vote), et les systèmes où le temps fait partie du domaine du discours (astronomie, recherche scientifique) pourraient exiger que de véritables horodatages soient montrés à l'utilisateur.

Cependant, la plupart des applications sont plus faciles à comprendre avec un simple temps relatif.

J'utilise généralement simplement l'heure Unix.pas nécessairement sûr pour l'avenir, mais cela fonctionne plutôt bien.

Stockez toujours en GMT (ou UTC).À partir de là, il est facile de convertir en n’importe quelle valeur de fuseau horaire local.

Les dates doivent être stockées au format UTC SAUF s'il s'agit de données fournies par l'utilisateur et que vous NE POUVEZ PAS savoir dans quel fuseau horaire l'utilisateur souhaitait que ces données se trouvent.Parfois (très très rarement), vous devez simplement stocker les composants heure, minute, seconde, jour, mois et année sans aucun fuseau horaire afin de pouvoir les restituer à l'utilisateur.Maintenant, pour les nouveaux développeurs ou si vous n'êtes pas sûr, stockez UTC et vous aurez raison à 99 %.

Mais ne vous laissez pas tromper en croyant que cela fonctionne à 100 % dans tous les cas, à tout moment.Ce ne est pas.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top