¿Qué es una forma práctica de almacenar las fechas para que los usuarios puedan ver y consultar datos en su propia hora local mientras se mantiene información sobre la fecha y hora original?Cómo almacenar las fechas en UTC y la zona horaria local
Básicamente, los usuarios desean poder consultar (a partir de su propia hora local) los datos recopilados de los sistemas en varias zonas horarias. Pero, de vez en cuando, quieren saber que los datos se crearon, digamos, a las 18:00 en el sistema original. Ayuda cuando los usuarios de diferentes partes del mundo se comunican sobre el mismo evento.
User1: What? We don't have any data for 20:00
User2: Dude, it says 20:00 right there on my screen.
User1: Wait, what timezone are you? What's the UTC-time?
User2: What is UTC? Is that something with computers?
User1: OMFG! *click*
Estoy buscando consejos sobre cómo almacenar los datos.
Estoy pensando en almacenar todas las fechas en UTC y agregar una columna adicional que contenga el nombre original de la zona horaria, en una forma que me permita usar mysql CONVERT_TZ, o la contraparte en Java. La aplicación convertiría las fechas ingresadas por el usuario en UTC y puedo consultar fácilmente la base de datos. Todas las fechas también se pueden convertir fácilmente a la hora local de los usuarios en la aplicación. Usando la columna original de la zona horaria también podría mostrar la fecha y hora original.
Sin embargo, esto significa que para cada fecha y hora que tengo, necesito una columna adicional ...
start_time_utc datetime
start_time_tz varchar(64)
end_time_utc datetime
end_time_tz varchar(64)
estoy en el camino correcto aquí?
¿Alguien que haya trabajado con esos datos compartirá sus experiencias?
(Me va a utilizar MySQL 5.5 CE)
Actualización 1
de datos será entregado en archivos XML que cada entrada tiene una fecha y hora en alguna zona horaria local. Entonces solo habrá un proceso de inserción, ejecutándose en un solo lugar.
Una vez cargado en la base de datos, se presentará en alguna aplicación web a usuarios en diferentes zonas horarias. Para la mayoría de los casos de uso, los datos de interés también se originaron en la misma zona horaria que el usuario que mira los datos. Para algunos de los casos de uso más complicados, una serie de eventos están interconectados y abarcan varias zonas horarias. Por lo tanto, los usuarios desean poder hablar de los eventos para investigar las posibles causas/consecuencias en el momento del otro. No es UTC, no es su hora local.
Para el problema en cuestión, creo que su solución es buena. –
¿MySQL no tiene 'DateTimeOffset', como MSSQL (un tipo de datos que especifica una marca de tiempo y su desplazamiento de UTC)? Si no es así, entonces su solución es el equivalente más cercano, que difiere solo en la cantidad de campos necesarios (1 frente a 2). – bzlm
No, MySQL no admite 'TIMESTAMP WITH TIMEZONE' (que es el tipo de datos ANSI para esto) –