Columbia Británica, zonas horarias y Postgres
El paso de Columbia Británica al horario de verano permanente está llevando a ingenieros a replantearse cómo almacenan fechas y horas en sistemas como Postgres. Los comentaristas debaten si los eventos futuros (como citas médicas o reuniones) deberían guardarse como marcas de tiempo UTC, como hora local de pared con una zona horaria IANA asociada, o con metadatos adicionales (ubicación, versión de tzdata, desplazamientos) para seguir siendo correctos cuando cambien las leyes o las reglas de DST. El consenso general es usar bibliotecas de zonas horarias probadas, tratar de forma distinta los eventos futuros y pasados, y aceptar que ningún esquema puede hacer que el tiempo futuro sea completamente estable cuando los gobiernos siguen reescribiendo las reglas.
Almacenar marcas de tiempo: UTC vs hora local
- Fuerte desacuerdo sobre “guardar siempre UTC”.
- Un bando dice: guardar solo marcas de tiempo Unix en UTC como fuente de verdad; convertir con bibliotecas de confianza; las zonas horarias son demasiado complejas para manejarlas manualmente.
- Otros sostienen que esto es un “error común” cuando importa la hora del reloj de pared (citas, fichajes, horario de oficina). La hora local existe de forma independiente de UTC y a menudo debería almacenarse directamente.
- Algunos enfatizan que UTC es apropiado para instantes literales (registros, eventos que ya ocurrieron), no para conceptos de dominio ligados a relojes locales.
Eventos futuros y cambios de zona horaria (caso de BC)
- Problema central: una cita futura fijada como “2pm hora local” puede corresponder a un instante UTC distinto si cambian las leyes (por ejemplo, si Columbia Británica pasa a horario de verano permanente).
- Esto obliga a elegir una referencia “autoritativa”:
- La hora local en el lugar del evento, o
- El instante UTC calculado originalmente, o
- La hora local de otro participante en reuniones entre varias zonas horarias.
- Varios comentaristas enfatizan que cualquier representación de eventos futuros es intrínsecamente provisional; los gobiernos y las fronteras pueden cambiar.
Estrategias de esquema y modelado
- Enfoques propuestos para eventos futuros:
- Guardar fecha/hora local + zona horaria IANA (por ejemplo,
America/Vancouver), opcionalmente junto con la ubicación. - Para citas, usar DATE/TIME o TIMESTAMP sin zona horaria para la hora local; convertir solo en la capa de presentación.
- Mantener un instante UTC adicional para consultas/optimización, pero dejar claro qué campo es el autoritativo.
- Guardar fecha/hora local + zona horaria IANA (por ejemplo,
- Para eventos pasados: muchos sugieren UTC, con zona horaria solo cuando la hora local de pared es semánticamente importante (por ejemplo, fichajes, análisis histórico).
- Algunos sugieren almacenar desplazamientos de zona horaria y/o la versión de tzdata o el momento de inserción para reconstruir la intención cuando cambian las reglas o los datos.
Bibliotecas, tzdata y complejidad
- Consenso: nunca reimplementar la lógica de zonas horarias; confiar en bibliotecas respaldadas por tzdata.
- Sin embargo, la propia tzdata cambia con frecuencia tanto para marcas de tiempo pasadas como futuras, y puede contener errores históricos.
- Ideas planteadas: sistemas que rastreen versiones de tzdata por registro, o usar estrategias tipo bitemporal para “lo que creíamos en ese momento”.
DST, política y reacción en BC
- Muchos critican el horario de verano en general y prefieren la hora permanente, pero discrepan sobre si es más saludable la hora estándar permanente o la hora de verano permanente.
- La decisión de Columbia Británica de adoptar horario de verano permanente es controvertida; a algunos residentes les gusta terminar con los cambios de reloj, otros argumentan que la consulta fue engañosa y que la hora estándar sería mejor.