¿Cuál es la mejor manera de representar las reglas de horario de verano?

Question

Necesito almacenar las reglas de cambio de horario de verano (horario de verano) para diferentes regiones del mundo en una base de datos. Ya tengo una forma de almacenar regiones y subregiones (por lo que se ocupa de todo el problema "half of Australia"/Arizona/Navaho), pero me pregunto cuál sería el esquema más eficiente para lograrlo. Las dos opciones como las veo:

• tiene una tabla que contiene única una fila para cada año y la región dando las horas de inicio y fin para el horario de verano, así como la específica de compensación
• tiene una tabla que almacena una fórmula y rango de fecha efectiva para cada región (alcance efectivo requerido para las regiones como Israel)

la ventaja de la primera es la flexibilidad, ya que literalmente nada es posible. Desafortunadamente, también requiere (a) más espacio y, por consiguiente, (b) mucho trabajo para obtener la entrada de datos. El segundo es bueno porque una fila podría corresponder a una región durante décadas, pero también requiere algún tipo de analizador de lenguaje e intérprete en la capa de aplicación. Dado que esta base de datos será utilizada por varias aplicaciones diferentes escritas en idiomas sin poderosas capacidades de procesamiento de texto, preferiría evitar esa ruta.

Me encantaría usar zoneinfo o algo así, pero desafortunadamente esa no es una opción en este caso. Del mismo modo, no puedo normalizar las fechas, la zona horaria y la información de horario de verano deben estar en la base de datos para satisfacer ciertos casos de uso.

¿Alguien tiene alguna experiencia haciendo algo similar? Del mismo modo, ¿alguien tiene alguna opción brillante que pueda haber perdido?

Answer 1

Estás condenado a la primera opción. Puede predeterminar las fechas con la anticipación que desee para los países que tienen "reglas" con respecto a los cambios de horario, pero algunas áreas no tienen ninguna regla y los cambios se promulgan por dictamen dictatorial o por votación legislativa anualmente (Brasil lo hizo hasta este año).

Esta es la razón por la cual todos los proveedores de sistemas operativos implementan cambios de archivos de zona horaria una o dos veces al año; tienen que hacerlo, porque no pueden generar un archivo 100% preciso mediante programación.

Answer 2

Si las reglas DST deben estar en la base de datos, probablemente elegiré actualizarlas automáticamente desde una fuente autorizada externa (biblioteca, sitio web, lo que sea). Manualmente mantener las reglas de DST no suena muy divertido.

Answer 3

Oracle DBMS maneja esto automáticamente para usted. La fecha se almacena en una representación interna (imaginemos UMT por el argumento) y se formatea de acuerdo con las reglas de la zona horaria cuando se convierte en una cadena.

Esto también resuelve el argumento sobre qué hacer durante el cambio en el tiempo. ES DECIR. cuando mueves el reloj hacia atrás 1/2 hora, en realidad hay 2 instancias de 3:25 a.m. en el mismo día.

Answer 4

Una de las mejores fuentes de información sobre las reglas de zona horaria es la base de datos Olson, que estaba disponible en elsie.nci.nih.gov. En septiembre de 2008, la versión actual de los datos era tzdata2008f.tar.gz, la versión actual del código era tzcode2008e.tar.gz (y sí, el código no siempre se publicaba cuando los datos). Esto tiende a ser la fuente de información para muchos otros sistemas (incluida, en particular, la información de Oracle). También hay una lista de correo disponible. Como puede ver, ha habido seis versiones de los datos hasta el momento en 2008; Tengo copias de 2005r, 2006l, 2007k al acecho en mi máquina, por lo que las cosas pueden cambiar con bastante frecuencia.

Hoy en día (marzo de 2017), la base de datos de Olson está disponible en IANA - vea https://iana.org/time-zones y ftp://ftp.iana.org/tz (especialmente ftp://ftp.iana.org/tz/releases).

También existe el Repositorio de datos de configuración regional común CLDR que también contiene información sobre las zonas horarias.