Almacenamiento de información horaria:¿Se requiere zona horaria?

De cualquier manera que lo haga, fallará de diferentes maneras dependiendo de lo que esté cambiando.

1. Si almacena marcas de tiempo en la zona horaria correspondiente como 2013-12-29 12:34:56 America/New_York , esto fallará si, por ejemplo, el Bronx repentinamente inicia su propia zona horaria America/New_York_Bronx con una compensación diferente y su evento resultó ser en el Bronx.

   Decida qué tan probable es esto y qué tan grave sería una falla.

2. Si almacena marcas de tiempo en UTC y la zona horaria en la que ocurre el evento está redefiniendo su compensación (por ejemplo, cambiando las fechas del horario de verano o cambiando por completo a una compensación diferente), la hora del evento puede diferir de la hora real del reloj de pared en esa ubicación. Si almacena 2013-12-29 12:34:56 UTC para un evento a las 13:34:56 en Berlín, Alemania, y Berlín cambia su horario de verano, 2013-12-29 12:34:56 UTC ahora puede corresponder a las 14:34:56 hora local de Berlín, mientras que el evento aún se está llevando a cabo a las 13:34 hora local.

   Decida qué tan probable es esto y qué tan grave sería una falla.

3. Si almacena la marca de tiempo UTC y la vincula a una ubicación física que luego vincula a una zona horaria, puede contrarrestar ambos problemas. Pero para esto tendrás que almacenar la ubicación física precisa, no solo "Nueva York", de lo contrario solo tienes el caso 1. con un paso intermedio más. Si almacena la ubicación física precisa y tiene una manera precisa de resolver esta ubicación en una zona horaria y mantiene su base de datos de zona horaria actualizada, puede manejar casi todos los escenarios de cambio.

   Decida qué tan práctico es esto y cuánto vale esta precisión adicional para usted.