Pourquoi ne stockez-vous pas UTC dans la base de données en premier lieu ? Dans la plupart des cas, DateTime doit être stocké en UTC, car il se réfère généralement à un point dans le temps. Cela est vrai pour tout ce qui se réfère au temps dans un sens physique, et tout ce qui suppose que le temps est monotone, croissant et unique, dont aucun n'est vrai pour la plupart des temps locaux.
Parfois, utiliser les heures locales a du sens :supposons qu'un bus parte tous les jours à 9 h 00. Cela signifie que 24 heures s'écoulent entre deux événements consécutifs. Cependant, si le fuseau horaire a un DST, ce sera un intervalle de 23h, respectivement 25h une fois par an.
Cependant, si vous avez besoin de gérer ce type de données, un simple DateTime ne fait pas l'affaire; Les règles DST peuvent changer, les fuseaux horaires peuvent changer, etc. En C#, les règles DST qui seront appliquées sont celles qui sont actuellement valable, même si la date est 'historique'. L'arithmétique des dates avec des dates historiques peut donc faire des ravages. Si vous avez vraiment besoin de faire face à cela, vous devriez au moins stocker quel le fuseau horaire dans lequel se trouve l'heure (pas seulement le décalage, ou même juste un isLocal drapeau).
Stocker des informations textuelles dans la base de données qui peuvent être stockées en binaire ne me semble pas très élégant, ni changer la valeur dans une couche intermédiaire. Le premier est inefficace et souffre des particularités de l'heure locale mentionnées précédemment, ce dernier n'a que le 2ème problème.
BTW, pour accomplir ce dernier, vous pouvez décorer la propriété avec [BsonDateTimeOptions(Kind=DateTimeKind.Local)] , qui fera la conversion pour vous, mais souffre des mêmes problèmes, bien sûr.
