Cuándo preferirías DateTime sobre DateTimeOffset

Question

Hace unos meses me presentaron el nuevo tipo DateTimeOffset y me alegré de que las fallas de DateTime con respecto a las zonas horarias finalmente se hubieran solucionado.

Sin embargo, me preguntaba si hubo algún problema o sobrecarga que podría ocurrir al usar este nuevo tipo.

Trabajo en una aplicación web multi-locale. ¿Alguien sabe de algo que me pueda convencer de usarlo para todo mi trabajo de fecha y hora? ¿Hay una ventana para el abuso aquí?

Referencia: DateTimeOffset: A New DateTime Structure in .NET 3.5 by Justin Van Patten

Answer 1

A veces lo que realmente quieres para representar un (conscientes zona horaria) Fecha "local" y el tiempo en lugar de un instantánea en el tiempo. Para ser sincero, a menudo es más útil representar solo un tiempo, p. "despiértame a las 8 a.m., independientemente de la zona horaria", pero la fecha y la hora también podrían ser útiles.

Acepto que para la gran mayoría de los casos, DateTimeOffset es un mejor ajuste. Me parece extraño que no haya una estructura DateTimeTimeZone que tenga tanto el instante como su zona horaria ... un desplazamiento en realidad no le proporciona toda la información que necesita. (Por ejemplo, dado un DateTimeOffset, no sabe cuál será el tiempo 24 horas después, porque no sabe cuándo podría activarse el DST).

Si quiere ese tipo de estructura, tengo un very crude implementation in another answer. Estoy seguro de que podría mejorarse muy fácilmente :)

Answer 2

Bueno, una respuesta obvia sería cuando necesitas admitir clientes sin el SP que se envía (en realidad no está en 3.5 - está en 2.0 SP1 , que se envió al mismo tiempo).