Scroll to navigation

archivos tz(5) Manual del Programador de Linux archivos tz(5)

NOMBRE

archivos tz - información de zona horaria

DESCRIPCIÓN

Los archivos de información de zona horaria utilizados por tzset(3) suelen encontrarse en el directorio /usr/share/zoneinfo o similar. Estos archivos utilizan el formato descrito en el RFC 8536. Cada archivo es una secuencia de bytes de 8 bits. En un archivo, un entero binario se representa mediante una secuencia de uno o más bytes en orden de red (bigendian o byte de orden superior primero), con todos los bits representativos, un entero binario con signo se representa mediante complemento a dos y un booleano se representará por un entero binario de un byte que es 0 (falso) o 1 (verdadero). El formato comienza con un encabezado de 44 bytes que contiene los siguientes campos:

  • La secuencia mágica ASCII de cuatro bytes “TZif” identifica el archivo como un archivo de información de zona horaria.
  • Byte que identifica la versión del formato del archivo (a partir de 2017, ya sea ASCII NUL o “2”, o “3”).
  • Quince bytes de ceros, reservando el espacio para algún uso futuro.
  • Seis valores enteros de cuatro bytes, en el siguiente orden:
Número de indicadores UT/locales almacenados en el archivo. (UT es hora universal).
Cantidad de indicadores estándar/pared almacenados en el archivo.
Cantidad de segundos durante los cuales se almacenan las entradas de datos en el archivo.
Cantidad de tiempos de transición para los que se almacenan las entradas de datos en el archivo.
Cantidad de tipos de hora local para los que se almacenan entradas de datos en el archivo (no debe ser cero).
Cantidad de bytes de de abreviaturas de zona horaria almacenadas en el archivo.

El encabezado anterior va seguido de los siguientes campos, cuyas longitudes dependen del contenido de dicho encabezado:

  • tzh_timecnt valores enteros con signo de cuatro bytes ordenados en orden ascendente. Estos valores se escriben en el orden de bytes de la red. Cada uno se utiliza como tiempo de transición (según lo devuelto por time(2)) en el que cambian las reglas para calcular la hora local.
  • tzh_timecnt valores enteros sin signo de un byte; cada uno, excepto el último, indica cuál de los diferentes tipos de hora local descritos en el archivo está asociado con el período de tiempo que comienza con el mismo tiempo de transición indexado y continúa hasta el siguiente tiempo de transición, pero sin incluirlo. (El tipo de última hora está presente solo para comprobar la coherencia con la cadena TZ de estilo POSIX que se describe a continuación). Estos valores sirven como índices en el siguiente campo.
  • tzh_typecnt ttinfo entradas, cada una definida de la siguiente manera: 

    struct ttinfo {
	int32_t	tt_utoff;
	unsigned char	tt_isdst;
	unsigned char	tt_desigidx;
};

    Cada estructura se escribe como un valor entero con signo de cuatro bytes para tt_utoff, en el orden de bytes de la red, seguido de un valor booleano de un byte para tt_isdst y un valor de un byte para tt_desigidx. En cada estructura, tt_utoff indica el número de segundos que se agregarán a UT, tt_isdst indica si tm_isdst debe establecerse mediante localtime(3) y tt_desigidx sirve como índice en la matriz de bytes de abreviatura de zona horaria que siguen a las estructuras ttinfo en el archivo. El valor tt_utoff nunca es igual a -2**31, para permitir que los clientes de 32 bits lo nieguen sin desbordarse. Además, en aplicaciones prácticas tt_utoff se sitúa en el intervalo [-89999, 93599] (es decir, más de -25 horas y menos de 26 horas); esto permite un fácil soporte por parte de implementaciones que ya admiten el rango requerido por POSIX [-24:59:59, 25:59:59].

  • tzh_leapcnt pares de valores de cuatro bytes, escritos en el orden de bytes de la red. El primer valor de cada par proporciona el tiempo positivo (según lo proporciona time(2)) en el que se produce un segundo intercalar. Este segundo es un entero con signo que indica el número total de segundos intercalares que se aplicarán durante el período de tiempo que comienza en el momento dado. Los pares de valores se ordenan en orden temporal ascendente. Cada transición es de un segundo intercalar, ya sea positivo o negativo, estando todas ellas siempre separadas entre si al menos 28 días menos 1 segundo.
  • tzh_ttisstdcnt indicadores estándar/pared, cada uno almacenado como un valor booleano de un byte. Indican si los tiempos de transición asociados con los tipos de hora local se expresan como hora estándar o como hora local (también llamada reloj de 'pared').
  • tzh_ttisutcnt indicadores UT/locales, cada uno almacenado como un valor booleano de un byte; Indican si los tiempos de transición asociados con los tipos de hora local se definieron como UT o como hora local. Si se configura un indicador UT/local, también se debe configurar el indicador estándar/pared correspondiente.

Los indicadores estándar/pared y UT/local fueron diseñados para transformar los tiempos de transición de un archivo TZif en transiciones apropiadas para otra zona horaria definida mediante una cadena TZ al estilo POSIX sin reglas. Por ejemplo, cuando TZ='EET-2EEST' y no existe ningún archivo TZif 'EET-2EEST', se trata de adaptar los tiempos de transición a partir de un archivo TZif con el conocido nombre 'posixrules' presente únicamente para este fin y que es una copia del archivo 'Europe/Brussels', un archivo con un desplazamiento UT diferente. POSIX no define este comportamiento obsoleto, las reglas predeterminadas dependen de la instalación y no se conoce ninguna implementación que admita esta característica para marcas de tiempo posteriores a 2037, por lo que los usuarios que deseen (por ejemplo) la hora griega deberían especificar TZ='Europe/Athens' para ser compatible con un mayor intervalo de tiempo, recurriendo a TZ='EET-2EEST,M3.5.0/3,M10.5.0/4' si se requiere conformidad POSIX y no siendo necesario manejar con precisión las marcas de tiempo más antiguas.

La función localtime(3) suele usar la primera estructura ttinfo en el archivo si tzh_timecnt es cero o el argumento de tiempo es menor que el primer tiempo de transición registrado en el archivo.

NOTAS

Esta página de manual documenta el archivo <tzfile.h> del código fuente de glibc, consulte timezone/tzfile.h.

Parece que la zona horaria usa tzfile internamente, pero glibc se niega a exponerlo al espacio de usuario. Lo más probable es que esto se deba a que las funciones estandarizadas son más útiles y portables, en realidad están documentadas por glibc. Es posible que solo esté en glibc para admitir los datos de zona horaria no gestionados por glibc sino por alguna otra entidad.

Formato de la versión 2

Para los archivos de zona horaria de versión 2, el encabezado y los datos van seguidos de un segundo encabezado y datos en el mismo formato salvo que se utilizan ocho bytes para cada tiempo de transición o segundo intercalar. Los recuentos de segundos intercalares siguen siendo de cuatro bytes. Al segundo encabezado y de los datos le siguen una cadena de estilo variable de entorno POSIX-TZ encerrada en nueva línea para usar en el manejo de instantes después del último tiempo de transición almacenado en el archivo o para todos los instantes si el archivo no tiene transiciones. La cadena TZ está vacía (es decir, no hay nada entre las nuevas líneas) si no hay representación POSIX para dichos instantes. Si no está vacía, la cadena TZ debe coincidir con el tipo de hora local después de la última hora de transición si está presente en los datos de ocho bytes. Dada la cadena “WET0WEST,M3.5.0,M10.5.0/3” entonces si el último tiempo de transición es en julio, el tipo de tiempo local de la transición debe definir un tiempo de cambio de hora verano/invierno abreviado “WEST” es una hora al este de UT. También, si hay al menos una transición, el tipo de tiempo 0 se asocia con el período de tiempo desde el pasado indefinido hasta, pero no inclusive, el primer tiempo de transición.

Formato de versión 3

Para archivos de zona horaria de la versión 3, la cadena de estilo POSIX-TZ puede usar dos extensiones menores del formato POSIX TZ, como se describe en newtzset(3). En primer lugar, las horas que forman parte de sus tiempos de transición pueden tener signo y oscilar entre -167 y 167 en lugar de los valores sin signo definidos POSIX de 0 a 24. En segundo lugar, el horario de verano está vigente todo el año si comienza el 1 de enero a las 00:00 y finaliza el 31 de diciembre a las 24:00 más la diferencia entre el horario de verano y el horario estándar.

Consideraciones de interoperabilidad

Los futuros cambios en el formato pueden añadir más datos.

Los archivos de la versión 1 se consideran un formato obsoleto y no deben emplearse al no admitir tiempos de transición posteriores al año 2038. Los lectores que solo entienden la versión 1 deben ignorar cualquier dato que se extienda más allá del final calculado del bloque de datos de la versión 1.

Las aplicaciones deben generar un archivo de versión 3 si son necesarias extensiones de cadena TZ para crear con precisión los tiempos de transición. De lo contrario, se deberían generar archivos de la versión 2.

La secuencia de cambios de tiempo definida por el encabezado y el bloque de datos de la versión 1 debe ser una secuencia contigua a los cambios de tiempo definidos por el encabezado y el bloque de datos de la versión 2+, y por el pie de página. Esta guía pretende ayudar a las aplicaciones obsoletas que usen la versión 1 a gestionar con otras más actuales las marcas de tiempo dentro de la secuencia contigua. También permite a las aplicaciones que no admitan estos formatos obsoletos a utilizar un tzh_timecnt de cero en el bloque de datos de la versión 1 para ahorrar espacio.

Las designaciones de zona horaria deberán consistir en al menos tres (3) y no más de seis (6) caracteres ASCII alfanuméricos, “-”, y “+”. Para preservar la compatibilidad con los requisitos de POSIX para las abreviaturas de zonas horarias.

Al leer un archivo de la versión 2 o 3, los lectores deben ignorar el encabezado y el bloque de datos de la versión 1, salvo para omitirlos.

Las aplicaciones que lean estos archivos debarán calcular las longitudes totales de los encabezados y bloques de datos y comprobar que todos ellos se ajustan dentro del tamaño real del archivo, como parte de la verificación de la validez del archivo.

Cuestiones comunes de interoperabilidad

En esta sección se detallan problemas comunes al leer o escribir archivos TZif. La mayoría suelen ser ocurrir durante la generación de archivos TZif para el uso de las aplicaciones más antiguas. Los objetivos de esta sección son:

  • ayudar a los creadores de archivos TZif a crear archivos que eviten los errores más habituales en lectores TZIF más antiguos o con mal implementados,
  • para ayudar a las aplicaciones que lean archivos TZif a evitar los errores más comunes al leer los archivos generados por futuras aplicaciones y
  • para ayudar a los futuros autores de definiciones a ver los problemas que surgen cuando se cambia el formato TZif.

Cuando se definieron nuevas versiones del formato TZif, uno de los objetivos en su diseño ha sido la posibilidad de utilizar con éxito cualquier archivo TZif incluso si el archivo es de una versión posterior para la que fue diseñado el lector. Cuando no se logre una compatibilidad completa, se intenta limitar los fallos a marcas de tiempo poco utilizadas y permitir soluciones parciales simples en los escritores diseñados para generar datos de nuevas versiones útiles incluso para lectores de versiones anteriores. Esta sección intenta documentar estos problemas de compatibilidad y soluciones alternativas, así como también documentar otros errores comunes en los lectores.

Los problemas de interoperabilidad con TZif incluyen los siguientes:

  • Algunas aplicaciones examinan sólo los datos de la versión 1. Como solución parcial, las aplicaciones que crean archivos TZif pueden sacar tantos datos de la versión 1 como sea posible. Sin embargo, al leerse deberán ignorarse los datos de la versión 1, y debe usar los datos en la versión 2+, incluso si los timestamps nativos del lector solo tienen 32 bits.
  • Algunos lectores diseñados para la versión 2 pueden gestionar incorrectamente las marcas de tiempo después de la última transición de un archivo de la versión 3, debido a que no pueden analizar extensiones de POSIX en la cadena tipo TZ. Como solución parcial, pueden generarse más transiciones de las necesarias, de modo que los lectores de la versión 2 solo gestionan incorrectamente las marcas de tiempo del futuro muy lejano.
  • Algunos lectores diseñados para la versión 2 no admiten el horario de verano permanente, por ejemplo, una cadena TZ “EST5EDT,0/0,J365/25” que denota el horario de verano permanente del este (-04). Como solución parcial, puede sustituirse la hora estándar por la siguiente zona horaria al este, por ejemplo: “AST4” para el Tiempo Estándar Atlántico permanente (-04).
  • Algunos lectores ignoran el final del bloque de datos, y en su lugar predicen las marcas de tiempo futuras a partir del tipo de tiempo de la última transición. Como solución parcial, pueden producirse más transiciones de las necesarias.
  • Algunos lectores no usan el tipo de tiempo 0 para las marcas de tiempo antes de la primera transición, sino que que deducen un tipo de tiempo de forma heurística y no siempre se selecciona el tiempo tipo 0. Como solución parcial, puede simularse una primera transición en los inicios.
  • Algunas aplicaciones que leer estos archivos, gestionan mal las marcas de tiempo antes de la primera transición que tiene una marca de tiempo no inferior a -2**31. Las que soportan sólo marcas de tiempo de 32 bits probablemente sean más propensas a este problema, por ejemplo, al procesar transiciones de 64 bits porque sólo algunas son representables en 32 bits. Como solución parcial, puede emitir una transición en la marca -2**31 aunque no es lo ideal.
  • Algunas aplicaciones gestionan mal una transición si su marca de tiempo tiene el valor mínimo posible de 64 bits con signo. No se recomiendan marcas de tiempo inferiores a -2**59.
  • Algunos lectores manejan incorrectamente las cadenas TZ de estilo POSIX que contienen “<” o “>”. Como solución parcial, puede evitarse el uso “<” o “>” para abreviaturas de zona horaria que contienen sólo caracteres alfabéticos.
  • Muchas aplicaciones gestionan incorrectamente las abreviaturas de zonas horarias que contienen caracteres que no ASCII por lo que no se recomienda su uso.
  • Algunas aplicaciones pueden gestionar mal las abreviaturas de zona horaria que contienen menos de 3 o más de 6 caracteres, o que contienen caracteres ASCII no alfanuméricos. “-”, y “+”. No se recomienda el uso de estas abreviaturas.
  • Algunas aplicaciones manejan mal los archivos TZif que especifican compensaciones UT del horario de verano menores que las compensaciones UT para la hora estándar correspondiente. Estos lectores no admiten ubicaciones como Irlanda, que utiliza el equivalente de la cadena POSIX TZ. “IST-1GMT0,M10.5.0,M3.5.0/1”, observando el horario estándar (IST, +01) en verano y el horario de verano (GMT, +00) en invierno. Como solución parcial podrían generarse datos para el equivalente de la cadena POSIX TZ “GMT0IST,M3.5.0/1,M10.5.0”, intercambiando así entre el horario estándar y el horario de verano. Aunque esta solución identifica erróneamente la parte del año que utiliza el horario de verano, si registra correctamente las compensaciones UT y las abreviaturas de zona horaria.

A continuación, se enumeran algunos problemas de interoperabilidad principalmente como advertencias para los desarrolladores de aplicaciones que lean estos archivos.

  • Algunas aplicaciones no admiten marcas de tiempo negativas. Los desarrolladores deberían tener esto en cuenta si necesitan trabajar con datos anteriores a 1970.
  • Algunos lectores manejan mal las marcas de tiempo antes de la primera transición que tiene una marca de tiempo no negativa. Es probable que los lectores que no admitan marcas de tiempo negativas sean más propensos a sufrir este problema.
  • Algunas aplicacines gestionan incorrectamente las abreviaturas de zona horaria como “-08” que contienen “+”, “-”, o dígitos.
  • Algunos lectores manejan mal las compensaciones UT que están fuera del intervalo tradicional de -12 a +12 horas. Por ejemplo, no admiten ubicaciones como Kiritimati al estar fuera de este intervalo.
  • Algunas aplicaciones gestionan incorrectamente las compensaciones UT en el intervalo [-3599, -1] segundos desde UT, porque dividen la compensación en números enteros entre 3600 para obtener 0 y luego muestran la parte horaria como “+00”.
  • Algunas aplicaciones gestionan incorrectamente las compensaciones UT que no son múltiplos de una hora, de 15 minutos o de 1 minuto.

VÉASE TAMBIÉN

time(2), localtime(3), tzset(3), tzselect(8), zdump(8), zic(8).

Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). 2019 Feb. Internet RFC 8536 doi:10.17487/RFC8536.

TRADUCCIÓN

La traducción al español de esta página del manual fue creada por Juan Piernas <piernas@ditec.um.es> y Marcos Fouces <marcos@debian.org>

Esta traducción es documentación libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD.

Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a debian-l10n-spanish@lists.debian.org.

9 Septiembre 2022 Linux