Stockage des informations de temps :Fuseau horaire requis ?

Quelle que soit la façon dont vous le faites, cela échouera de différentes manières en fonction de ce qui change.

1. Si vous stockez les horodatages dans le fuseau horaire correspondant sous la forme 2013-12-29 12:34:56 America/New_York , cela échouera si, par exemple, le Bronx démarre soudainement son propre fuseau horaire America/New_York_Bronx avec un décalage différent et votre événement s'est avéré être dans le Bronx.

   Décidez de la probabilité et de la gravité d'un échec.

2. Si vous stockez les horodatages en UTC et que le fuseau horaire dans lequel l'événement se produit redéfinit leur décalage (par exemple, en décalant les dates DST ou en décalant entièrement vers un décalage différent), l'heure de l'événement peut différer de l'heure réelle de l'horloge murale à cet endroit. Si vous stockez 2013-12-29 12:34:56 UTC pour un événement à 13:34:56 à Berlin, Allemagne, et Berlin change son heure d'été, 2013-12-29 12:34:56 UTC peut maintenant correspondre à 14:34:56 heure locale de Berlin, alors que l'événement se déroule toujours à 13:34 heure locale.

   Décidez de la probabilité et de la gravité d'un échec.

3. Si vous stockez l'horodatage UTC et le liez à un emplacement physique que vous liez ensuite à un fuseau horaire, vous pouvez contrer les deux problèmes. Mais pour cela, vous devrez stocker l'emplacement physique précis, pas seulement "New York", sinon vous avez juste le cas 1. avec une étape intermédiaire de plus. Si vous stockez l'emplacement physique précis et avez un moyen précis de résoudre cet emplacement en fuseau horaire et que vous maintenez votre base de données de fuseaux horaires à jour, vous pouvez gérer à peu près tous les scénarios de changement.

   Décidez à quel point cela est pratique et combien cette précision supplémentaire vaut pour vous.