Columbia Británica, zonas horarias y Postgres

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.
• 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.