Quand préféreriez-vous DateTime à DateTimeOffset?

Question

Il y A quelques mois j'ai été présenté à la nouvelle - DateTimeOffset type et se réjouit DateTimes'défauts concernant les fuseaux horaires ont finalement été pris en charge.

Cependant, je me suis demandé s'il y avait des frais généraux ou des problèmes qui pourraient résulter de l'utilisation de ce nouveau type.

Je travaille sur un multi-locale de l'application web. Personne ne sait de quoi que ce soit qui pourrait me balancent de l'utiliser pour tous mes date/heure de travail? Est-il une fenêtre pour abus ici?

Référence: DateTimeOffset: Une Nouvelle Structure DateTime dans .NET 3.5 par Justin Van Patten

Answer 1

Parfois, vous avez vraiment juste envie de représenter un "local" (fuseau horaire pas au courant) la date et l'heure, plutôt que d'un instantané dans le temps. Pour être honnête, c'est plus souvent utile de représenter qu'un temps - par exemple, "me réveiller à 8h du matin, quel que soit le fuseau horaire" - mais aussi de la date et de l'heure pourrait être utile aussi.

Je suis d'accord que pour la grande majorité des cas, DateTimeOffset est un meilleur ajustement. Il ne me paraît bizarre qu'il n'y a pas un DateTimeTimeZone struct qui a à la fois de l'instant et son fuseau horaire si... un décalage ne fait pas de vous donner toutes les informations dont vous avez besoin. (Par exemple, étant donné un DateTimeOffset, vous ne savez pas ce que le temps sera de 24 heures plus tard, parce que vous ne savez pas quand l'heure d'été peut-coup de pied.)

Si vous voulez ce genre de structure, j'ai un très brut de mise en œuvre dans une autre réponse. Je suis sûr que ça pourrait être améliorée très facilement :)

Answer 2

Eh bien, une réponse évidente serait lorsque vous devez prendre en charge des clients sans le SP dans lequel il est livré (ce n'est pas réellement dans la version 3.5 - c'est dans la version 2.0 SP1, qui a été livrée au même moment).