Resumen

  • RFC 9636 normaliza el formato TZif, pero no declara de dónde proceden las reglas reunidas en cada archivo ni que sean la edición más reciente.
  • El bloque legado, la tabla de 64 bits, los límites de truncamiento, el footer y la caducidad de saltos de segundo recortan la autoridad del resultado.
  • El recibo une intención, identificador de zona, fuente y versión, hash, intervalo, lector, decisión ante ambigüedades y efecto final.

El desfase era correcto. La zona no era la que la persona quiso indicar.

Ese error puede sobrevivir a todos los controles sintácticos. Varias zonas comparten hoy un desfase y divergen cuando cambia una norma. Una abreviatura como CST tampoco identifica por sí sola China, Cuba o Norteamérica. Antes de abrir el archivo ya existe una decisión: qué zona representa el lugar o la intención civil.

RFC 9636 estandariza los bytes que permiten resolver esa zona. Sustituye a RFC 8536, conserva compatibilidad e introduce la versión 4. Pero dice expresamente que no define la fuente de los datos. La base de zonas horarias de IANA es una fuente posible, no una propiedad implícita de cualquier objeto que empiece por TZif.

Un archivo, dos épocas de lector

La primera cabecera y el primer bloque son siempre de versión 1. Sus tiempos de 32 bits sólo llegan de 1901 a 2038. Las versiones 2 y posteriores añaden una segunda tabla de 64 bits y un footer. Mantienen delante la parte antigua para compatibilidad.

Un escritor puede dejar en ese bloque antiguo un marcador mínimo. El lector obsoleto interpreta que no hay cambios de hora; el lector moderno salta a la tabla completa. Por tanto, registrar “parse correcto” sin versión del lector y bloque utilizado oculta una discrepancia prevista por el diseño.

Hay que conservar hash y tamaño del objeto, versión, contadores, validación de límites, tabla consultada, biblioteca y edición de la fuente. La reproducibilidad no nace del desfase final, sino de esa cadena.

La cobertura puede terminar antes que el archivo

Cada transición señala un tipo local con desfase, estado DST y designación. El tipo rige hasta la siguiente transición. Si falta información después de la última y el footer está vacío, la hora futura queda sin especificar.

TZDIST puede entregar un archivo truncado. Es válido dentro de un intervalo declarado por sus transiciones límite. Antes o después, el tipo -00 permite decir que no se conoce la hora local. No es un error que deba esconderse: es una respuesta precisa sobre el alcance de la evidencia.

Un sistema que reutiliza el último desfase fuera del intervalo toma una decisión propia. Puede ser una política aceptada, pero debe tener dueño, versión y señal visible. El archivo no la autorizó.

El footer extrapola, no legisla

En versiones 2+, el footer puede contener una regla POSIX que continúa después de la última transición almacenada. Debe coincidir con esa transición en la frontera. La coherencia interna no convierte la regla en conocimiento de futuras decisiones civiles.

Si una autoridad cambia su calendario, la base publica otra edición. Los eventos futuros deben entonces conservar suficiente intención para decidir si se mantiene el instante, la hora de pared o se pide confirmación. Un UTC desnudo no puede explicar después qué quería el organizador.

RFC 9557 puede adjuntar una zona nombrada a una marca temporal y RFC 5545 modela calendarios. Aun así, el mensaje no contiene necesariamente la edición TZif ni la política con la que se resolvió una hora repetida o inexistente.

La expiración también es un dato

La versión 4 permite truncar al comienzo la tabla de saltos de segundo y usar el último registro como fecha de caducidad. Después, la tabla ya no informa si habrá otra corrección.

Un lector puede negarse a procesar esos instantes o continuar ignorando la caducidad con una indicación de error. Las dos conductas no tienen el mismo valor probatorio. Los registros deben distinguir “calculado pese a caducidad” de “cubierto por una tabla vigente”.

La resolución de la 27.ª CGPM sobre el futuro de los saltos de segundo no demuestra qué tabla instaló una máquina. La decisión institucional, la edición distribuida y la rama ejecutada por el lector son capas diferentes.

TLS no corrige una edición antigua

TZif carece de integridad y confidencialidad propias. Sus arrays contados exigen comprobar tamaños e índices. La distribución pública debe protegerse con una capa externa como TLS, porque reglas alteradas pueden dañar horarios.

TLS demuestra un canal hacia un extremo, no que el extremo haya servido la fuente correcta, que el ETag sea reciente o que la caché local se actualizara. El recibo de distribución debe incluir fuente, edición, URL, ETag, hora de descarga, hash, edad de caché e instalación.

La consulta de una zona también puede revelar ubicación pasada, presente o futura. Aunque las reglas sean públicas, la elección del usuario merece control de acceso.

Del cálculo al efecto

Una cadena defendible separa siete pasos: intención; zona; fuente y edición; archivo y rango; lector y política; hora resultante; decisión y efecto de la aplicación. Una hora de pared que aparece dos veces necesita elegir la primera o la segunda. Una hora inexistente necesita rechazo, desplazamiento o consulta. RFC 9636 describe la geometría; no decide la intención.

El estándar tiene autoridad sobre el significado de los bytes. No certifica el lugar elegido, la vigencia legal, la caché, la política del calendario ni que una ventana de mantenimiento comenzara cuando debía.

Fuentes