example - tamaño datetime sql server
Almacenamiento de DateTime(UTC) contra el almacenamiento de DateTimeOffset (3)
A DATETIMEOFFSET le permite almacenar la hora local y la hora UTC en un campo.
Esto permite un informe muy simple y eficiente en tiempo local o UTC sin la necesidad de procesar los datos para su visualización de ninguna manera.
Estos son los dos requisitos más comunes: hora local para informes locales y hora UTC para informes grupales.
La hora local se almacena en la parte DATETIME del DATETIMEOFFSET y el OFFSET de UTC se almacena en la parte OFFSET, por lo que la conversión es simple y, dado que no requiere conocimiento de la zona horaria de la que provienen los datos, todo puede hacerse a nivel de base de datos. .
Si no necesita tiempos de milisegundos, por ejemplo, solo minutos o segundos, puede usar DATETIMEOFFSET (0). El campo DATETIMEOFFSET solo requerirá 8 bytes de almacenamiento, lo mismo que DATETIME.
El uso de DATETIMEOFFSET en lugar de UTC DATETIME por lo tanto brinda más flexibilidad, eficiencia y simplicidad para los informes.
Normalmente tengo un "interceptor" que justo antes de leer / escribir desde / hasta la base de datos hace la conversión de DateTime (de UTC a la hora local, y de la hora local a UTC), así que puedo usar DateTime.Now (derivaciones y comparaciones) en todo el sistema sin preocuparse por las zonas horarias.
En cuanto a la serialización y el traslado de datos entre computadoras, no hay necesidad de molestarse, ya que la fecha y hora es siempre UTC.
¿Debo continuar almacenando mis fechas (SQL 2008 - datetime) en formato UTC o en su lugar debería almacenarlo usando DateTimeOffset (SQL 2008 - datetimeoffset)?
Las fechas UTC en la base de datos (tipo de fecha y hora) han estado funcionando y se conocen desde hace tanto tiempo, ¿por qué cambiarlas? ¿Cuáles son las ventajas?
Ya he analizado artículos como este , pero no estoy 100% convencido. ¿Alguna idea?
Hay una gran diferencia, donde no puede usar UTC solo.
Si tienes un escenario como este
- Un servidor y varios clientes (todos geográficamente en diferentes zonas horarias )
- Los clientes crean algunos datos con información de fecha y hora
- Los clientes lo almacenan todo en el servidor central
Entonces:
- datetimeoffset almacena la hora UTC y también se compensa con la hora local del cliente
- todos los clientes conocen la hora UTC de todos los datos y también la hora local en el lugar donde se originó la información
Pero:
- UTC datetime almacena solo el horario de UTC , por lo que no tiene información sobre la hora local en la ubicación del cliente donde se originaron los datos
- Otros clientes no conocen la hora local del lugar, de donde proviene la información de fecha y hora
- Otros clientes solo pueden calcular su hora local desde la base de datos (usando la hora UTC), no la hora local del cliente, donde se originaron los datos.
Ejemplo simple es el sistema de reserva de boleto de vuelo ... El boleto de vuelo debe contener 2 veces: - hora de "despegue" (en la zona horaria de la ciudad "De") - hora de "aterrizaje" (en la zona horaria de la ciudad de "Destino")
Tiene toda la razón al usar UTC para todos los tiempos históricos (es decir, grabar eventos ocurridos). Siempre es posible pasar de UTC a hora local pero no siempre a la inversa.
Cuándo usar la hora local? Responde esta pregunta:
Si el gobierno repentinamente decide cambiar el horario de verano, ¿le gustaría que estos datos cambien con él?
Solo almacene la hora local si la respuesta es "sí". Obviamente, eso solo será para fechas futuras, y generalmente solo para fechas que afectan a las personas de alguna manera.
¿Por qué almacenar una zona horaria / desplazamiento?
En primer lugar, si desea registrar el desplazamiento para el usuario que realizó la acción, probablemente sea mejor que lo haga, es decir, al iniciar sesión, registre la ubicación y la zona horaria de ese usuario.
En segundo lugar, si desea convertir para visualizar, necesita tener una tabla de todas las transiciones de compensación de tiempo local para esa zona horaria, simplemente sabiendo que la compensación actual no es suficiente, porque si está mostrando una fecha / hora de hace seis meses, la compensación sé diferente.