Cómo mapear tiempos locales históricamente precisos en Java cuando cambian las reglas de zona horaria?

time calendar

Question

Tengo una base de datos que contiene marcas de tiempo UTC (GMT + 0). Aquí está el problema: se refieren a la actividad de facturación que ocurrió en el estado de Indiana.

Como algunos pueden saber, Indiana ...

• no observó Horario de verano antes del 2006 (la mayoría del estado fue EST durante todo el año).
• votó en 2006 para permanecer EST, pero para comenzar a observar el horario de verano con el resto de los EE. UU.
• revisó sus reglas en 2007; el Gobierno Federal de EE. UU. revisó el horario de verano para que cambien las reglas de inicio y fin

Debido a que las marcas de tiempo en esta base de datos se refieren a la actividad de facturación del gobierno, en realidad es necesario tener las marcas de tiempo UTC informadas como las horas locales que son históricamente precisas para preservar la precisión de la auditoría. Por lo tanto, existen tres escenarios que se aplican exclusivamente a Indiana: las marcas de tiempo antes del 2006 usan un conjunto completamente diferente de reglas de zona horaria que las del período 2006-2007, y las posteriores al 2007 usan otro conjunto completamente diferente de reglas de zona horaria. Puedes imaginar que esta base de datos incluye actividades para locales que no sean Indiana, por lo que las cosas se complican aún más.

El calendario de Java y la API de TimeZone no contienen ninguna clase que permita al programador crear objetos con más de un conjunto de reglas de zona horaria, por lo que no se pueden usar para la asignación correcta de marcas de tiempo UTC a horas locales históricamente precisas si la zona horaria específica aplicable las reglas cambian alguna vez

He pensado en formas de abordar el problema del mapeo a tiempos locales históricamente precisos en locales con las cambiantes reglas de zona horaria ...

• La base de datos se podría actualizar para que las marcas de tiempo UTC se puedan almacenar junto con el desplazamiento de hora local y una compensación de horario de verano. El problema aquí es que el tamaño de la base de datos aumenta un poco y si la base de datos existente es grande, la actualización de todas las tablas puede requerir un ciclo de mantenimiento fuera de línea extendido.

• La base de datos se puede actualizar para que el objeto TimeZone particular apropiado para esa marca de tiempo particular se almacene con cada marca de tiempo. Aunque creo que los objetos TimeZone son bastante livianos, veo que esto es más flexible que el anterior pero aún menos deseable ya que requiere persistir un objeto para cada marca de tiempo.

• Se puede desarrollar una API personalizada que cree un objeto TimeZone apropiado a partir de una base de datos de reglas históricamente precisas para los lugares de interés. Esta solución reemplaza el mayor requisito de almacenamiento de las dos soluciones anteriores con la necesidad de un procesamiento adicional. Cada marca de tiempo que debía mostrarse significaría crear un nuevo objeto ... o al menos vincularlo con un objeto apropiado de un conjunto de objetos. Además, significa crear y administrar una base de datos de zona horaria.

Las limitaciones de Java Time y Calendar API han hecho que encontrar una solución elegante a este problema sea realmente más difícil de lo que debería (no puede, por ejemplo, consultar un objeto SimpleTimeZone existente y preguntarle qué reglas de ahorro de luz natural sigue sin escribir código realmente desordenado).

Solo me gustaría preguntar si alguien más ha lidiado con una situación como esta antes y cómo la han manejado.

Answer 1

La base de datos de zona horaria que está describiendo ya existe . Se llama base de datos de zona info de Olson, es correcta para todas las fechas posteriores a 1970, y está disponible en línea .

Mejor aún, las API nativas de fecha y hora de Java usan esta base de datos. Puede cargar un huso horario arbitrario usando java.util.TimeZone.getTimeZone() , y obtener compensaciones o realizar conversiones utilizando este objeto (por ejemplo, usando TimeZone.getOffset(long) . Por ejemplo, cargaría el "America/Indiana/Indianapolis" zona para convertir fechas y horas en Indiana.

Lo único que no puede hacer fácilmente con la base de datos TimeZone es consultar las reglas que está usando. Por eso, creo que tendrías que profundizar en los archivos tz directamente. Sin embargo, en la mayoría de los casos, solo obtener compensaciones para las fechas especificadas debería ser suficiente.