Ubuntu Manpage: archivos tz - información de zona horaria

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.

• 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:

tzh_ttisutcnt
Número de indicadores UT/locales almacenados en el archivo. (UT es hora universal).

tzh_ttisstdcnt
Cantidad de indicadores estándar/pared almacenados en el archivo.

tzh_leapcnt
Cantidad de segundos durante los cuales se almacenan las entradas de datos en el archivo.

tzh_timecnt
Cantidad de tiempos de transición para los que se almacenan las entradas de datos en el archivo.

tzh_typecnt
Cantidad de tipos de hora local para los que se almacenan entradas de datos en el archivo (no debe
ser cero).

tzh_charcnt
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 de ellos, 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 último tipo de hora está presente solo para verificar la
coherencia con la cadena TZ de estilo POSIX.1-2017 que se describe a continuación. Estos valores
servirán como índices en 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 escribirá como un valor entero de cuatro bytes con signo para tt_utoff, en orden
de bytes según la red, seguido de un valor booleano de un byte para tt_isdst y de otro byte para
tt_desigidx. Para cada estructura, tt_utoff dará 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 es el índice en el
vector de bytes de abreviatura de zona horaria que van después de 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 tt_utoff nunca es igual a -2**31, para permitir que los clientes de
32 bits lo nieguen sin dar error. Además, en aplicaciones en productivo tt_utoff está en el
intervalo [-89999, 93599] (es decir, más de -25 horas y menos de 26 horas). Esto hace que sea
sencillo proporcionar soporte a las 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 el orden de bytes de la red; el primer
valor de cada par proporciona el tiempo no negativo (según lo devuelto por time(2)) en el que se
produce un segundo intercalar o en el que caduca la tabla de segundos intercalares; el segundo valor
es un entero con signo que define 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 en orden estrictamente ascendente en base al tiempo. Cada par denota un segundo intercalar,
ya sea positivo o negativo, excepto que si el último par tiene la misma corrección que el anterior,
el último par denota el tiempo de vencimiento de la tabla de segundos intercalares. Cada segundo
intercalar se produce al final de un mes de calendario UTC. El primer segundo intercalar tiene un
tiempo de aparición no negativo y es un segundo intercalar positivo si y sólo si su corrección es
positiva; la corrección para cada segundo intercalar después del primero difiere del segundo
intercalar anterior en 1 para un segundo intercalar positivo o -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 de tiempo; de lo contrario, para las marcas de tiempo anteriores a la
hora de la primera aparición, la corrección del segundo intercalar es cero si la corrección del
primer par es 1 o -1, y en caso contrario no se especifica (lo que solo puede ocurrir en archivos
truncados 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 fueron diseñados para transformar los tiempos de transición de
un archivo TZif en transiciones apropiadas para otra zona horaria especificada a través de una cadena TZ
al estilo POSIX.1-2017 que carece de reglas. Por ejemplo, cuando TZ='EET2EEST' y no hay archivo TZif '
EET *-2EAST', la idea era adaptar los tiempos de transición de un archivo de TZIF con el conocido nombre
'posixrules' que está presente sólo para este propósito y es una copia del archivo 'Europe/Brussels',
archivo con un espaciado UT diferente. POSIX no define este comportamiento de transformación obsoleto,
las reglas predeterminadas son dependientes del sistema, y no se conoce ninguna implementación que
soporte esta característica para marcas de tiempo más allá de 2037, por lo que los usuarios que deseen
(por ejemplo) hora griega deberán indicar TZ='Europa/Atenas' para mayor seguridad, volviendo a
TZ='EET2EEST,M3.5.0/3,M10.5.0/4' si se requiere conformidad con POSIX y no necesita manejar con precisión
las marcas de tiempo 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.

NOTAS

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

It seems that timezone(3) uses tzfile internally, but glibc refuses to expose it to userspace. This is
most likely because the standardised functions are more useful and portable, and actually documented by
glibc. It may only be in glibc just to support the non-glibc-maintained timezone data (which is
maintained by some other entity).

Formato de la versión 2
Para los archivos de zona horaria de esta segunda versión del formato, al encabezado y los datos
anteriores le sigue un segundo encabezamiento y datos, idénticos en formato, salvo que se usan ocho bytes
para cada tiempo de transición o segundo intercalar. Se siguen disponiendo de 4 bytes para el recuento de
segundos intercalares.Después del segundo encabezado y de los datos viene una cadena encerrada entre
nuevas líneas al estilo del contenido de una variable de entorno POSIX.1-2017 TZ, 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 arquivo no tiene transiciones. La cadena TZ estará vacía (es decir, no hay nada entre las nuevas
lineas) si no hay representación en el estilo POSIX.1-2017 para esos instantes. Si no está vacío, la
cadena TZ debe coincidir con el tipo de tiempo local después del último tiempo 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 de formato de versión 3, la cadena TZ puede usar dos extensiones menores
del formato POSIX 1-2017 TZ, tal como se describe en newtzset(3). En primer lugar, la parte de las horas
de sus tiempos de transición pueden tener signo y varían entre -167 y 167 en lugar de los valores
requeridos por POSIX (entre 0 y 24). En segundo lugar, el horario de verano está en vigor durante 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 la hora 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
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.

Uno de los objetivos al definir nuevas versiones del formato TZif ha sido que un lector pueda usar un
archivo TZIF incluso si el archivo es de una versión posterior para la que el lector fue diseñado. Cuando
no se logra una compitbilidad total, se intenta limitar los errores a las marcas de tiempo menos
frecuentes y permitir soluciones parciales simples para que las nuevas aplicaciones puedan generar
archivos legibles para aquellas aplicaciones diseñadas para interpretar versiones más antiguas. Esta
sección intenta documentar estosproblemas de compatibilidad aportando soluciones, así como documentar
otros errores comunes en la interpretación que las aplicaciones hacen de estos archivos.

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 manipular mal los timestamps después de la
última transición de un archivo de la versión 3 o superior, porque no pueden analizar las
extensiones de POSIX.1-2017 en la cadena similar a TZ. Como solución parcial, pueden producirse más
transiciones de las necesarias, de modo que sólo los lectores de la versión 2 manipulen
incorrectamente las marcas de tiempo del futuro.

• 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 tiempo estándar
nunca utilizado (XXX, -03) y horario de verano negativo (EDT, -04), durante todo el año.
Alternativamente, como una solución parcial puede sustituirse el tiempo estándar para la próxima
zona horario al este – e.g., “AST4” para el Tiempo Estándar Atlántico permanente (-04).

• Algunas aplicaciones diseñadas para la versión 2 o 3 requieren una estricta conformidad con RFC 8536
y por tanto rechazan los archivos de la versión 4 cuyas tablas de segundos intercalares están
truncadas al comienzo o que terminan en tiempos de caducidad.

• 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.

• Algunas aplicaciones manejan incorrectamente las cadenas TZ 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 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 el desplazamiento UTC no es múltiplo de 60 segundos. Por ejemplo, en una zona horaria con
diferencia UTC +01:23:45 y con un segundo intercalar positivo 78796801 (1972-06-30 23:59:60 UTC),
algunos lectores asignarán tanto 78796800 como 78796801 a las 01:23:45 hora local al día siguiente
en lugar de asignar este último a las 01:23:46, y asignarán 78796815 a las 01:23:59 en lugar de a
las 01:23:60. Esto todavía no ha sido un problema práctico, ya que ninguna autoridad civil ha
observado tales compensaciones UTC desde que se introdujeron 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 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. El formato de información de zona horaria (TZif). 2019  febrero  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.

Base de Datos de Zonas Horarias                                                                   archivos tz(5)