Le stockage DateTime (UTC) vs stockage DateTimeOffset

Question

D'habitude, j'ai un "interceptor" que juste avant la lecture et l'écriture dans la base de données datetime conversion (UTC à localtime, et de localtime à l'utc), donc je peux l'utiliser DateTime.Maintenant (les dérivations et les comparisions) dans l'ensemble du système sans se soucier de fuseaux horaires.

Concernant la sérialisation et de déplacement des données entre les ordinateurs, il n'y a pas besoin de s'embêter, comme le datetime est toujours UTC.

Dois-je continuer à stocker mes dates (SQL 2008 - datetime) au format UTC ou devrais-je plutôt que de le stocker à l'aide de DateTimeOffset (SQL 2008 - datetimeoffset)?

UTC Dates dans la base de données (de type datetime) ont travaillé et connu depuis si longtemps, pourquoi le changer? Quels sont les avantages?

J'ai déjà regardé dans les articles comme les ce l'un, mais je ne suis pas convaincu à 100% que. Toutes les pensées?

Answer 1

Il y a une différence énorme, où vous ne pouvez pas utiliser UTC seul.

• Si vous avez scénario comme celui-ci

  • Un serveur et plusieurs clients (tous géographiquement dans différents fuseaux horaires)
  • Les Clients de créer des données avec des informations de datetime
  • Les Clients de le stocker sur le serveur central

• Alors:

  • datetimeoffset magasins de l'heure UTC et AUSSI de décalage de l'heure locale du client
  • tous les clients connaissent l'heure UTC de toutes les données et également, heure locale, dans le lieu où l'information est originaire

• Mais:

  • UTC datetime magasins juste UTC datetime, de sorte que vous n'avez pas d'informations sur l'heure locale, dans l'emplacement du client l'origine des données
  • Les autres clients ne sais pas l'heure locale du lieu où datetime est venue l'information
  • Les autres clients ne peut calculer l'heure locale de la base de données (à l'aide de l'heure UTC) ne sont pas l'heure locale du client, à l'endroit où les données proviennent

Exemple Simple est le billet d'avion le système de réservation de ... billet d'avion doit contenir 2 fois: - "take off" (dans le fuseau horaire "à Partir" de la ville) - "l'atterrissage" du temps (dans le fuseau horaire "Destination" de la ville)

Answer 2

Vous avez tout à fait correct d'utiliser l'UTC pour tous les temps historiques (c'est à dire l'enregistrement des événements happenned). Il est toujours possible d'aller de l'UTC en heure locale, mais pas toujours le contraire.

Lors de l'utilisation de l'heure locale? Répondre à cette question:

Si le gouvernement soudainement décider de changer l'heure d'été, voulez-vous les données de changer avec lui?

Seul magasin, heure locale, si la réponse est "oui". Évidemment, ce ne sera que pour des dates futures, et généralement uniquement pour les dates qui touchent les gens d'une certaine façon.

Pourquoi stocker un fuseau horaire/offset?

Tout d'abord, si vous souhaitez enregistrer ce que le décalage était pour l'utilisateur qui a effectué l'action, vous serait probablement mieux le faire juste que, c'est à dire à l'ouverture de session d'enregistrement de l'emplacement et du fuseau horaire de l'utilisateur.

Deuxièmement, si vous voulez les convertir pour les afficher, vous devez disposer d'un tableau de toutes décalage de l'heure locale de transitions pour que le fuseau horaire, il suffit de connaître le décalage actuel n'est pas assez, parce que si vous montrez une date/heure à partir de il ya six mois, le décalage sera différent.

Answer 3

DATETIMEOFFSET vous donne la possibilité de stocker l'heure locale et l'heure UTC dans un champ.

Cela permet très simple et efficace de déclaration dans le local ou à l'heure UTC, sans la nécessité de traiter les données pour l'affichage d'une quelconque façon.

Ce sont les deux raisons les plus courantes - temps local pour les rapports locales et l'heure UTC pour les rapports de groupe.

L'heure locale est stocké dans le type DATETIME partie de la DATETIMEOFFSET et le DÉCALAGE entre l'heure UTC est stocké dans le DÉCALAGE de la partie, donc la conversion est simple et, car il ne nécessite pas la connaissance de l'horaire les données proviennent d', peut être fait au niveau base de données.

Si vous ne nécessitent pas le temps en millisecondes, par exemple, juste pour quelques minutes ou quelques secondes, vous pouvez utiliser DATETIMEOFFSET(0). Le DATETIMEOFFSET champ, puis seulement besoin de 8 octets de stockage - même comme un DATETIME.

À l'aide d'un DATETIMEOFFSET plutôt que d'un UTC DATETIME donc donne plus de flexibilité, d'efficacité et de simplicité pour les rapports.