El software que calcula desfases de zona horaria suele suponer implícitamente que la regla actual de una zona se ha aplicado siempre, y esa suposición funciona bien justo hasta que necesitas interpretar correctamente una marca de tiempo anterior al último cambio de regla, momento en el que produce silenciosamente una respuesta errónea que parece totalmente verosímil. Es una fuente realmente habitual de corrupción sutil de datos en sistemas que almacenan o procesan marcas de tiempo históricas a lo largo de un periodo considerable.
Esto importa porque las reglas de zona horaria, las fechas de inicio y fin del horario de verano, los desfases estándar e incluso la zona a la que pertenece una ubicación, no son fijas para siempre. Cambian cuando los gobiernos las cambian, como se explica en otro artículo, y una marca de tiempo registrada hace años necesita la regla que estaba realmente vigente en esa fecha concreta, no la regla vigente hoy, para calcular el momento correspondiente correcto en otra zona o en UTC.
Precisamente por eso la base de datos de zonas horarias de la IANA guarda un historial completo de cambios de regla para cada zona con nombre, y no solo la regla actual. Un software construido correctamente sobre ella puede responder a "cuál era el desfase UTC de esta zona en esta fecha histórica concreta", que es una pregunta realmente distinta y más compleja que "cuál es el desfase UTC de esta zona ahora mismo", y confundirlas es exactamente la forma en que los datos históricos de marcas de tiempo se van desviando sin que nadie lo note.
Esto se manifiesta de formas concretas y prácticas. Un sistema que convierte la marca de tiempo de un registro histórico de hora local a UTC para analizarlo necesita la regla histórica de la fecha y la zona originales de ese registro, no la actual, o la conversión introduce un error que puede llegar a una hora completa en cualquier sentido, según la transición concreta de que se trate. Un sistema que calcula la edad de una persona o la duración de un contrato entre fechas que abarcan un cambio histórico de regla necesita el mismo cuidado, aunque ahí el impacto suele ser menor. Incluso mostrar a un usuario una marca de tiempo antigua en su hora local actual requiere convertirla mediante la regla histórica correcta de la zona y la fecha originales, no la actual.
La recomendación práctica es calcular siempre las conversiones de zona horaria con un sistema que conozca los cambios históricos de regla de la zona y la fecha en cuestión, en lugar de uno que solo conozca la regla actual, y tener especial cuidado con cualquier proceso que convierta por lotes datos históricos a lo largo de un periodo que pueda incluir un cambio de regla. Nuestra consulta de zona horaria se puede consultar para un momento concreto en el tiempo, aplicando las reglas que estaban realmente vigentes en esa fecha, que es exactamente el comportamiento necesario para tratar correctamente los datos históricos en lugar de aplicar por defecto la regla de hoy a cada cálculo, sea cual sea la fecha que se esté procesando realmente.