Est-ce toujours une bonne idée de stocker l'heure en UTC ou est-ce le cas où il est préférable de stocker l'heure locale ?

Question

En règle générale, la meilleure pratique consiste à stocker le temps en UTC et, comme indiqué dans le document aquí y aquí .

Supposons qu'il existe un événement récurrent, par exemple l'heure de fin, qui est toujours à la même heure locale, par exemple 17:00, que l'heure d'été soit activée ou désactivée pour ce fuseau horaire. Il est également nécessaire de ne pas modifier l'heure manuellement lorsque l'heure d'été est activée ou désactivée pour un fuseau horaire donné. Il est également nécessaire que lorsque l'heure de fin est demandée par un autre système via l'API (c'est-à-dire GetEndTimeByEvent), il envoie toujours l'heure de fin au format UTC.

Approche 1 : S'il est décidé à stocker en UTC il peut être stocké dans la table de la base de données comme ci-dessous.

Event      UTCEndTime
=====================
ABC         07:00:00
MNO         06:00:00
PQR         04:00:00

Pour le premier événement ABC, l'heure de fin en UTC est 07h00, ce qui, si l'on convertit l'affichage de l'UTC à l'heure locale le 1er juillet 2012, donnera 17h00 heure locale et, si l'on convertit le 10 octobre 2012 (date à laquelle l'heure d'été est activée pour le fuseau horaire), donnera 18h00, ce qui n'est pas l'heure de fin correcte.

Une solution possible serait de stocker l'heure d'été dans la colonne supplémentaire et d'utiliser cette heure lorsque le fuseau horaire est activé.

Approche 2 : Toutefois, s'il est enregistrée comme heure locale comme ci-dessous, par exemple pour l'événement ABC, il sera toujours 17:00 à n'importe quelle date, car il n'y a pas de conversion de l'heure UTC à l'heure locale.

Event      LocalEndTime
=======================
ABC         17:00:00
MNO         16:00:00
PQR         14:00:00

Une couche applicative convertit l'heure locale en heure UTC pour l'envoyer à d'autres systèmes (API GetEndTimeByEvent).

Est-ce toujours une bonne idée de stocker l'heure en UTC dans ce cas ? Si oui, comment obtenir une heure locale constante ?

Questions connexes : Y a-t-il jamais une bonne raison de stocker l'heure autrement qu'en UTC ?

Answer 1

En fait, vous ne stockez pas un point précis dans le temps, comme le supposent la plupart des API temporelles. Utilisez des intervalles si votre base de données le supporte (PostgreSQL le supporte) ou stockez-le comme un entier représentant le nombre de secondes (minutes/heures) depuis minuit ou le début correspondant de l'horaire (lundi, premier du mois, etc.). Dans un cas comme dans l'autre, vous n'avez plus à vous soucier de la façon dont le "temps" est géré d'un système à l'autre, et vous n'avez plus qu'à convertir les secondes en heure du jour dans votre vue, ce qui n'est pas très compliqué.

Answer 2

Ne peut-on pas toujours calculer l'heure locale à partir de l'UTC et d'un fuseau horaire ? Nous ne pouvons pas vraiment stocker de manière fiable une heure et un fuseau horaire encodés dans l'heure elle-même puisque les décalages des fuseaux horaires peuvent changer et que la norme ISO ne nous permet que d'encoder le décalage qui pourrait changer. Nous ne pouvons donc pas, par exemple, stocker une heure future encodée dans le fuseau horaire local puisque nous ne connaissons pas encore le décalage ! Il faut donc stocker les heures en UTC et stocker le fuseau horaire dans une entrée séparée et le calculer lorsque cela est nécessaire, ce qui est moins sujet aux erreurs. L'heure locale est généralement un détail d'implémentation. Il semble que lorsque nous la stockons, nous mélangeons probablement les préoccupations. La plupart du temps, c'est le rôle de la vue d'afficher l'heure en fonction des fuseaux horaires. C'est en stockant les composants des choses et en permettant aux calculs de les composer que l'on obtient le plus de flexibilité en règle générale.