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

Je pense que pour répondre à cette question, nous devrions réfléchir aux avantages de l'utilisation de l'UTC pour stocker les horodatages.

Personnellement, je pense que le principal avantage est que l'heure est toujours (ou presque) garantie. cohérent . En d'autres termes, chaque fois que le fuseau horaire est modifié ou que l'heure d'été est appliquée, il n'y a pas de retour en arrière ou d'avancée dans le temps. Cela est particulièrement utile pour les systèmes de fichiers, les journaux, etc. Mais est-ce nécessaire dans votre application ?

Pensez à deux choses. Tout d'abord, au moment du passage à l'heure d'été. Est-il probable que vos événements se déroulent entre 2 et 3 heures du matin (le jour du changement d'heure) ? Que devrait-il se passer à ce moment-là ?

Deuxièmement, l'application sera-t-elle soumise à des changements de fuseau horaire ? En d'autres termes, allez-vous prendre l'avion de Londres à Varsovie et modifier le fuseau horaire de votre ordinateur en conséquence ? Que se passera-t-il dans ce cas ?

Si vous avez répondu non à ces deux questions, il est préférable d'utiliser l'heure locale. Cela simplifiera votre candidature. Mais si vous avez répondu oui au moins une fois, je pense que vous devriez y réfléchir davantage.

---

Et il ne s'agissait que de la base de données. L'autre élément est le format de temps utilisé en interne par l'application, et cela devrait dépendre de ce que vous ferez réellement avec ce temps.

Vous avez mentionné l'exposition de l'heure via une API. L'application interrogera-t-elle la base de données à chaque demande ? Si vous stockez l'heure en interne en UTC, vous devrez soit le faire, soit vous assurer qu'en cas de changement d'heure ou de fuseau horaire, les heures mises en cache seront ajustées/élaguées.

Cela aura-t-il un effet sur le temps lui-même ? Comme l'impression l'événement aura lieu dans 8 heures ou en se suspendant pendant environ cette période ? Si c'est le cas, l'UTC sera probablement préférable. Bien entendu, il faut tenir compte de toutes les questions susmentionnées.

Answer 2

J'aime penser à cela de la manière suivante :

Les ordinateurs ne s'intéressent pas au temps en tant que représentation compréhensible par l'homme. Ils ne se soucient pas des fuseaux horaires, du formatage des chaînes de date et d'heure, etc. Seuls les humains s'intéressent à la manière d'interpréter et de représenter le temps.

Laissez la base de données faire ce qu'elle sait faire : stocker le temps sous la forme d'un nombre - soit une époque UNIX (nombre de secondes écoulées depuis le 1er janvier 1970), soit un horodatage UTC (sans information sur le fuseau horaire ou l'heure d'été). Ne vous préoccupez de représenter le temps d'une manière compréhensible pour l'homme que lorsque c'est nécessaire. C'est-à-dire dans votre logique d'application, votre système de reporting, votre application console ou tout autre endroit où un être humain visualisera les données.

Answer 3

Ce qui suit ne s'appliquerait pas à un produit SaaS global véritablement multi-tenant, c'est pourquoi cet avis s'adresse aux simples développeurs d'applications "Line of Business".

Le stockage en tant qu'UTC est une bonne chose, mais il y a une exigence qui cause des problèmes si vous faites cela : "Pouvez-vous m'écrire un rapport qui me montre combien de X se produisent par jour ?"

Si vous stockez les dates en UTC, cette exigence vous causera des difficultés ; vous devrez écrire un code d'ajustement du fuseau horaire sur le serveur d'application et dans vos rapports ; chaque requête ad hoc que vous effectuez sur des données comprenant des critères de date devra tenir compte de cette exigence.

Si votre demande répond aux critères suivants :

1. Chaque instance est basée sur un seul fuseau horaire.
2. Les changements de fuseau horaire se font généralement en dehors des heures de bureau, ou bien vous ne vous souciez pas vraiment de la "durée" des choses au point qu'une heure manquante ait de l'importance.

Je vous suggère de stocker la date en tant que date locale, tout en utilisant une bibliothèque qui vous isole des problèmes de configuration du fuseau horaire du serveur (par exemple Noda.Time dans le monde .net).

Answer 4

Si vos messages intersystèmes utilisent la norme ISO 8601 et que votre base de données stocke l'heure locale d'origine + le décalage (comme dans le cas suivant datetimeoffset dans MSSQL ou ISODate dans Mongo selon la norme ISO 8601) et que vous n'utilisez que des DateTimeOffset en .NET ou OffsetDateTime en Java ou un équivalent dans votre code, alors aucune conversion n'est nécessaire. Il suffit de le stocker. Toutes les fonctions de comparaison fonctionneront.

Si vous convertissez en UTC dans votre persistance, vous perdez le décalage du point de vue de l'utilisateur. Afficher la date à laquelle l'utilisateur a signé un document il y a dix ans devient un problème difficile à résoudre. Pour le faire à partir de l'UTC, il faudra rechercher les règles de l'heure avancée qui étaient en vigueur à cette époque dans ce territoire. Cauchemar.

Je pense que la raison pour laquelle nous sommes tous tellement habitués à convertir en UTC pour la persistance est que nous n'avons jamais eu les bonnes structures de données/types de données pour nous permettre de faire ce qu'il faut.

Answer 5

Je me contenterais de stocker le composant Heure uniquement, sans aucune zone. Lorsque l'API doit la servir, elle ajoute la date correcte et convertit l'heure locale en UTC pour cette date.

Base de données = 17:00 (utiliser un horodatage sans date, heures sous forme d'octet, minutes sous forme d'octet, chaîne)

Récupérer = Date à laquelle nous voulons l'événement + Base de données 17:00 => Convertir la date locale en UTC

De cette manière, vous servirez toujours l'heure correcte en UTC.