1. Manuals
  2. Tumbleweed
  3. man-pages-es
  4. tzfile(5)

Scroll to navigation

archivos tz(5) File Formats Manual 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) se encuentran generalmente en un directorio con un nombre similar a /usr/share/zoneinfo. Estos archivos utilizan el formato descrito en el RFC 9636. 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 (Big Endian, o el byte de orden superior primero), con todos los bits significativos; un entero binario con signo se representa mediante complemento a dos; y un booleano se representa mediante un entero binario de un byte que es 0 (falso) o 1 (verdadero). El formato comienza con una cabecera 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.
  • Un byte que identifica la versión del formato del archivo (a partir de 2021, ya sea ASCII NUL, “2”, “3”, o “4”).
  • 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 (tal como retorna 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 la hora de transición con el mismo índice y continúa hasta la siguiente hora de transición, pero sin incluirla. (El último tipo de hora está presente solo para comprobar la coherencia con la cadena TZ proléptica que se describe a continuación). Estos valores sirven como índices para el siguiente campo.
  • tzh_typecnt ttinfo entradas, cada una de ellas 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 orden de bytes de red, seguido de un 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 añadirá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 entradas ttinfo en el archivo; si la cadena designada es '-00', la entrada ttinfo es un marcador de posición que indica que la hora local no está definida. El valor de tt_utoff nunca es igual a -2**31, para que los clientes de 32 bits puedan negarlo sin desbordarse. Además, en aplicaciones realistas, tt_utoff se encuentra en el rango [-89999, 93599] (es decir, más de -25 horas y menos de 26 horas); esto facilita la compatibilidad con implementaciones que ya admiten el rango requerido por POSIX [-24:59:59, 25:59:59].

  • tzh_charcnt bytes que representan designaciones de zona horaria. Son cadenas de bytes terminadas en null, cada una de ellas indexada por los valores tt_desigidx mencionados anteriormente. Las cadenas de bytes pueden superponerse si una es un sufijo de la otra. No se especifica la codificación de estas cadenas.
  • tzh_leapcnt pares de valores de cuatro bytes, escritos en orden de bytes de red; el primer valor de cada par indica el tiempo no negativo (devuelto por time(2)) en el que se produce un segundo intercalar o en el que expira la tabla de segundos intercalares; el segundo es un entero con signo que especifica la corrección, que es 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 estrictamente en orden temporal ascendente. Cada par representa un segundo intercalar, positivo o negativo, excepto que si el último par tiene la misma corrección que el anterior, este último representa la fecha de expiración de la tabla de segundos intercalares. Cada segundo intercalar corresponde al final de un mes calendario UTC. El primer segundo intercalar tiene una fecha de ocurrencia no negativa y es positivo solo si su corrección es positiva; la corrección de cada segundo intercalar posterior al primero difiere de la del segundo intercalar anterior en 1 para un segundo intercalar positivo o en -1 para un segundo intercalar negativo. Si la tabla de segundos intercalares está vacía, la corrección del segundo intercalar es cero para todas las marcas temporales; de lo contrario, para las marcas de tiempo anteriores a la primera fecha de ocurrencia, la corrección del segundo intercalar es cero si la corrección del primer par es 1 o -1, y no se especifica en caso contrario (lo que solo puede ocurrir en archivos recortados al inicio).
  • tzh_ttisstdcnt indicadores estándar/pared, cada uno almacenado como un byte booleano; ellos dicen si los tiempos de transición asociados con los tipos de tiempo local fueron especificados como tiempo estándar o local (hora del reloj de pared).
  • tzh_ttisutcnt Indicadores UT/locales. Cada uno almacenado como un byte booleano, indicarán si los tiempos de transición asociados con los tipos de tiempo locales se definieron como UT o tiempo local. Si se establece un indicador UT/local, también debe establecerse el indicador estándar/pared correspondiente.

Los indicadores estándar/pared y UT/local se diseñaron para transformar los tiempos de transición de un archivo TZif en transiciones adecuadas para otra zona horaria especificada mediante una cadena TZ proléptica sin reglas. Por ejemplo, cuando TZ='EET-2EEST' y no existe un archivo TZif 'EET-2EEST', la idea era adaptar los tiempos de transición de un archivo TZif con el conocido nombre 'posixrules', que existe únicamente para este fin y es una copia del archivo 'Europe/Brussels', un archivo con una diferencia horaria UT diferente. POSIX no define los detalles de este comportamiento transformacional obsoleto, las reglas predeterminadas dependen de la instalación y no se conoce ninguna implementación que admita esta función para marcas de tiempo posteriores a 2037, por lo que los usuarios que deseen (por ejemplo) la hora griega deben especificar TZ='Europe/Athens' para una mejor cobertura histórica, y recurrir a TZ='EET-2EEST,M3.5.0/3,M10.5.0/4' si se requiere conformidad con POSIX y no es necesario manejar con precisión las marcas de tiempo más antiguas.

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

Formato de la versión 2

Para los archivos de zona horaria en versión 2 del formato, el encabezado y los datos anteriores van seguidos de un segundo encabezado y datos, idénticos en formato, excepto que se utilizan ocho bytes para cada tiempo de transición o segundo intercalar. (Los segundos intercalares siguen ocupando cuatro bytes). Tras el segundo encabezado y los datos, se incluye una cadena delimitada por una nueva línea, similar al contenido de una zona horaria proléptica, para el manejo de instantes posteriores a la última hora de transición almacenada en el archivo o para todos los instantes si el archivo no tiene transiciones. La cadena de zona horaria está vacía (es decir, no contiene nada entre las nuevas líneas) si no existe una representación proléptica para dichos instantes. Si no está vacía, la cadena de zona horaria debe coincidir con el tipo de hora local posterior a la última hora de transición, si está presente en los datos de ocho bytes. Por ejemplo, dada la cadena “WET0WEST,M3.5.0/1,M10.5.0” 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 con formato de la versión 3, una cadena TZ (véase newtzset(3)) puede usar las siguientes extensiones POSIX.1-2024 a POSIX.1-2017: Primero, como en TZ='<-02>2<-01>,M3.5.0/-1,M10.5.0/0', la parte horaria de sus tiempos de transición puede tener signo y estar comprendida entre -167 y 167, en lugar de limitarse a valores sin signo de 0 a 24. Segundo, como en TZ='XXX3EDT4,0/0,J365/23', el horario de verano está vigente todo el año si comienza el 1 de enero a las 00:00 y termina el 31 de diciembre a las 24:00, más la diferencia entre el horario de verano y el horario estándar.

Formato de versión 4

Para los archivos TZif en la versión 4 del formato, el primer segundo intercalar puede tener una corrección distinta de +1 y de -1, para representar la partición al inicio del archivo TZIF. Asimismo, si hay dos o más transiciones de segundo intercalar y la corrección de la última entrada es igual a la anterior, la entrada última denota la expiración de la tabla de segundos intercalares en lugar de denotar la de un segundo intercalar. Las marcas de tiempo después de esta expiración son poco fiables y es probable que se añadan entradas de segundos intercalares después de dicho expirado, que cambiarán la forma en que se tratan las marcas de tiempo posteriores a ese instante.

Consideraciones de interoperabilidad

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

Los archivos de la versión 1 se consideran obsoletos y no deben emplearse. No admiten tiempos de transición después del año 2038. Las aplicaciones que sólo entienden la versión 1 deben ignorar cualquier dato que se extienda más allá del final del bloque de datos de la versión 1.

Aparte de la versión 1, las aplicaciones que cree estos archivos deben generar el número de versión más bajo necesario para trabajar con los datos de un archivo. Por ejemplo, se debe generar un archivo de versión 4 sólo si su tabla de segundos intercalares expira o se truncó al inicio. Una aplicación que no genera un archivo de versión 4 debería generar un archivos de versión 3 sólo si las extensiones de cadenas TZ son necesarias para gestionar con precisión los tiempos de transición.

La secuencia de cambios de hora definida por el encabezado de la versión 1 y el bloque de datos deben ser una subsecuencia contigua de los cambios de hora definidos por el encabezado de las versiones 2+, el bloque de datos y por el pie. Esta guía ayuda a las aplicaciones que utilicen la (obsoleta) versión 1 para que hagan la misma interpretación de las marcas de tiempos dentro de la subsecuencia contigua. También permite, a las aplicaciones que generan estos archivos y que no consideran a los lectores más antiguos, usar un tzh_timecnt de cero en el bloque de datos de la versión 1 para ahorrar espacio.

Cuando un archivo TZif indica la fecha de caducidad de la tabla de segundos intercalares, los lectores de TZIF no deberían procesar marcas de tiempo posteriores a esta fecha, o procesarlos como si no existiera esta fecha de caducidad incluso indicándolo con un mensaje de error.

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 versión 2 o superior, se deberá ignorar el encabezado de la versión 1 y el bloque de datos, simplemente saltándolos.

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.

Cuando debe introducirse un segundo de intercalación, las aplicaciones deben añadir un segundo adicional al minuto local que contiene el segundo justo antes de dicho segundo de intercalación. Si esto ocurre cuando el desvío UTC no es un múltiplo de 60 segundos, el segundo de intercalación se introduce antes que el último segundo del minuto local y los segundos locales restantes del minuto se numeran a través de 60 en lugar de 59 que sería lo habitual. No afecta al desplazamiento UTC.

Cuestiones comunes de interoperabilidad

Esta sección documenta problemas comunes al interpretar o escribir archivos TZif. La mayoría de estos problemas se producen al generar archivos TZif para lectores antiguos. Los objetivos de esta sección son:

  • Que los lectores TZif generen archivos que eviten los problemas comunes de los lectores TZif antiguos o de por sí defectusoso;
  • Que los lectores TZif eviten los problemas comunes al leer archivos generados por futuros lectores TZif; y
  • Que los futuros autores de especificaciones detecten los problemas que surgen al cambiar el formato TZif.

Al definir nuevas versiones del formato TZif, un objetivo de diseño ha sido que un lector pueda usar correctamente un archivo TZif incluso si se trata de una versión posterior para la que fue diseñado. Cuando no se consiga una compatibilidad completa, se intenta limitar los fallos a las marcas de tiempo poco utilizadas y permitir soluciones alternativas simples en los lectores diseñados para generar datos de versiones más recientes, útiles incluso para lectores de versiones anteriores. Esta sección intenta documentar estos problemas de compatibilidad y sus soluciones alternativas, así como 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 manejar incorrectamente las marcas de tiempo después de la última transición de un archivo de la versión 3 o superior, porque no pueden analizar las extensiones POSIX.1-2024 a POSIX.1-2017 en la cadena TZ proléptica. Como solución parcial, una aplicación puede generar más transiciones de las necesarias, de modo que los lectores de la versión 2 solo gestionen incorrectamente las marcas de tiempo de un futuro lejano.
  • Algunos lectores diseñados para la versión 2 no permiten tener el horario de verano con transiciones después de las 24:00 – por ejemplo, una cadena TZ) “EST5EDT,0/0,J365/25” Indicando el horario de verano del este permanente (-04). Como solución, puede sustituirse el tiempo estándar por dos zonas horarias al este, por ejemplo, “XXX3EDT4,0/0,J365/23” para una zona horaria con un horario estándar nunca utilizado (XXX, -03) y un horario de verano negativo (EDT, -04) durante todo el año. Como alternativa, solución temporal parcial, puede sustituirse la hora estándar por la siguiente zona horaria este –, por ejemplo, “AST4” para el Tiempo Estándar Atlántico permanente (-04).
  • Algunos lectores diseñados para la versión 2 o 3 y que requieren una conformidad estricta con la RFC 9636 rechazan los archivos de la versión 4 cuyas tablas de segundos intercalares se truncan al principio o al final de los tiempos de expiración.
  • 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 simplificados ignoran todo excepto el pie de página y usan su cadena TZ proléptica para calcular todas las marcas de tiempo. Aunque este enfoque suele funcionar para las marcas de tiempo actuales y futuras, obviamente tiene problemas con las marcas de tiempo pasadas e incluso para las marcas de tiempo actuales puede fallar para configuraciones como TZ="Africa/Casablanca". Esto corresponde a un archivo TZif que contiene transiciones explícitas hasta el año 2087, seguido de un pie de página que contiene la cadena TZ “<+01>-1”, que debe usarse solo para las marcas de tiempo posteriores a la última transición explícita.
  • 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.
  • Algunos lectores gestionan incorrectamente las marcas de tiempo antes de la primera transición con un marca de tiempo no inferior a -2**31. Los lectores que solo admiten marcas de tiempo de 32 bits probablemente sean más propensos a este problema, por ejemplo, cuando procesan transiciones de 64 bits, de las cuales solo algunas son representables en 32 bits. Como solución temporal, puede generarse una transición ficticia en la marca de tiempo -2**31.
  • 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 gestionan incorrectamente las cadenas TZ prolépticas 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.
  • Algunos lectores pueden gestionar incorrectamente 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 inferiores a las compensaciones UT para la hora estándar correspondiente. No admiten ubicaciones como Irlanda, que utiliza el equivalente de la cadena 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, un escritor puede generar datos para el equivalente de la cadena 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.
  • Algunos lectores generan marcas de tiempo ambiguas para segundos intercalares positivos que ocurren cuando la diferencia UTC no es múltiplo de 60 segundos. Por ejemplo, con una diferencia UTC de +01:23:45 y un segundo intercalar positivo de 78796801 (1972-06-30 23:59:60 UTC), algunos lectores asignarán tanto 78796800 como 78796801 a la 01:23:45 hora local del día siguiente en lugar de asignar este último a la 01:23:46, y asignarán 78796815 a la 01:23:59 en lugar de a la 01:23:60. Esto aún no se ha dado en la práctico, ya que ninguna autoridad civil ha observado tales diferencias UTC desde la introducción de los segundos intercalares en 1972.

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 gestionan incorrectamente las marcas de tiempo antes de la primera transición que tiene una marca de tiempo no negativa. Lectores que no admiten marcas de tiempo negativas Es probable que sean más propensos a 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.
  • Algunos lectores gestionan incorrectamente las diferencias de tiempo universal (UT) en el rango [-3599, -1] segundos con respecto a UT porque dividen la diferencia 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. El formato de información de zona horaria (TZif). Octubre de 2024. Internet RFC 9636 doi:10.17487/RFC9636.

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.

Base de Datos de Zonas Horarias