Inspector de archivos TZif (zoneinfo)

Cómo usar

1. Suelta un archivo de zona compilado en el recuadro: cópialo de /usr/share/zoneinfo, sácalo de un contenedor con docker cp o de un JDK.
2. Lee primero el resumen: la versión, cuántas transiciones trae y si el futuro está enumerado (fat), delegado en la regla POSIX (slim) o fijo para siempre.
3. Compara las dos columnas de la cabecera. Un archivo slim muestra un bloque de 32 bits casi vacío junto a uno de 64 bits lleno; esa diferencia es el formato funcionando, no un daño.
4. Mira el instante de referencia y la próxima transición para saber qué haría hoy este archivo y cuándo cambia.
5. Abre la sección del pie POSIX si el archivo es slim: sus reglas M, J o de base cero son lo único que gobierna cualquier fecha posterior a la última transición.

Preguntas frecuentes

¿Por qué la cabecera muestra dos juegos de contadores?

Porque un archivo de versión 2 o posterior contiene los datos dos veces. Empieza con un bloque de versión 1 completo, cuyos instantes de transición son de 32 bits, y solo después llegan una segunda cabecera, un bloque de 64 bits y el pie POSIX. La duplicación existe para que un lector escrito antes de 2004 encuentre algo que entiende en lugar de fallar, y el RFC 8536 indica a los lectores modernos que salten directamente al segundo bloque. Por eso los contadores pueden diferir: con la salida slim de zic el primer bloque se reduce a un tipo de hora local y ninguna transición, mientras el segundo guarda los datos reales. Si una herramienta dice que una zona no tiene historia, casi siempre está leyendo el bloque heredado por error, algo que todavía hacen algunas bibliotecas.

¿En qué se diferencian un archivo fat y uno slim?

Describen la misma zona; cambia cuánto futuro escriben. Un archivo fat enumera todas las transiciones hasta 2037, de modo que Europe/Berlin trae unas 140 y el cambio del próximo octubre se lee directamente en la tabla. Uno slim se detiene en la última transición que no puede deducirse de una regla y deja el resto al pie POSIX, por lo que puede ocupar la décima parte. Desde 2020 zic genera slim por omisión, pero las distribuciones difieren: Debian y Ubuntu siguen publicando archivos fat, y Alpine y varias imágenes base de contenedor publican slim. Un lector que ignore el pie funciona bien con un archivo fat y se equivoca en silencio con uno slim, que es justo el tipo de fallo que aparece en una imagen y no en otra.

¿Cómo se lee el pie POSIX y qué significan M, J y el número suelto?

El pie es la misma cadena que puede contener la variable TZ: abreviatura estándar, desfase estándar y, opcionalmente, la abreviatura de verano, su desfase y las dos reglas que alternan entre ambos. Sus desfases van con el signo de POSIX, positivo al oeste de Greenwich, así que CET-1 significa UTC+01:00 y esta herramienta le da la vuelta al signo. Una regla admite tres formas. Mm.w.d es mes, semana (5 significa la última) y día de la semana, de modo que M3.5.0 es el último domingo de marzo. Jn es el día n del año contando desde 1 y sin contar nunca el 29 de febrero, así que J60 siempre es el 1 de marzo. Un número suelto cuenta desde 0 y sí cuenta el 29 de febrero, así que 59 es el 1 de marzo en un año común y el 29 de febrero en uno bisiesto. Esta última forma es rara y conviene evitarla: las implementaciones no coinciden, y zoneinfo de Python la resuelve un día más tarde que glibc.

¿Por qué Etc/GMT+5 indica un desfase de -05:00?

Porque los nombres Etc siguen el convenio de signos de POSIX, que es el contrario al que usa todo el mundo: en una cadena TZ, positivo significa al oeste de Greenwich. Así que Etc/GMT+5 es la zona cinco horas por detrás de UTC, que en ISO 8601 y en cualquier interfaz se escribe -05:00, y Etc/GMT-5 es la que va cinco horas por delante. La base de datos tz conserva estos nombres precisamente porque POSIX exige ese comportamiento, y advierte de que son una trampa. Esta herramienta muestra los desfases al modo ISO, así que un archivo cuyo nombre dice +5 y cuyo desfase dice -05:00 no es una contradicción ni un error: es el convenio de nombres asomando.

¿Qué son los registros de segundo intercalar y por qué las transiciones parecen raras en un archivo right/?

La base de datos tz se puede compilar de dos maneras: el árbol posix/ habitual, donde una marca de tiempo cuenta segundos sin intercalares, y el árbol right/, donde los segundos intercalares desde 1972 se guardan como registros y las marcas cuentan segundos realmente transcurridos. La mayoría de los sistemas solo distribuyen el primero, así que una tabla de intercalares aquí significa que tienes un archivo right/ o uno compilado con zic -L. En esos archivos las transiciones aparecen desplazadas por la corrección acumulada: un cambio que debería leerse 01:00:00 se lee 01:00:27, porque desde 1972 se han insertado 27 segundos intercalares, y la columna de corrección sube hasta ese mismo 27. Mezclar un archivo right/ en un sistema que espera tiempos posix/ es la forma clásica de ir exactamente 27 segundos desviado.

¿Puede decirme de qué zona es este archivo o si está corrupto?

No en ninguno de los dos casos, y ambos límites son propiedades del formato. Un archivo TZif no contiene ningún nombre: la identidad de una zona viene solo de su ruta en la base de datos, y por eso un enlace como Asia/Istanbul es una copia byte a byte de Europe/Istanbul, o un enlace simbólico a él, y no se distingue por su contenido. Lo máximo que puedes hacer es reconocer la zona por su huella: las abreviaturas, los desfases y las fechas de las transiciones, que es para lo que sirven estas tablas. Tampoco hay ninguna suma de verificación en el formato, así que un byte cambiado en la tabla de transiciones no invalida el archivo, solo desplaza en silencio una transición o la apunta a otro tipo. Lo único detectable es una longitud que ya no cuadra con los contadores, y eso es lo que esta herramienta rechaza como truncado.

Herramientas relacionadas