archivos tz(5)

NOMBRE
archivos tz - información de zona horaria

DESCRIPCIÓN
The timezone information files used by tzset(3) are typically found under a directory with a name like /usr/share/zoneinfo. These files use the format described in Internet RFC 9636. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), with all bits significant, a signed binary integer is represented using two's complement, and a boolean is represented by a one-byte binary integer that is either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields:

    •   La secuencia mágica ASCII de cuatro bytes 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, o

    •   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, 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;
        };

        Each structure is written as a four-byte signed integer value for tt_utoff, in network byte order, followed by a one-byte boolean for tt_isdst and a one-byte value for tt_desigidx. In each structure, tt_utoff gives the number of seconds to be added to UT, tt_isdst tells whether tm_isdst should be set by localtime(3) and tt_desigidx serves as an index into the array of time zone abbreviation bytes that follow the ttinfo entries in the file; if the designated string is "-00", the ttinfo entry is a placeholder indicating that local time is unspecified. The tt_utoff value is never equal to -2**31, to let 32-bit clients negate it without overflow. Also, in realistic applications tt_utoff is in the range [-89999, 93599] (i.e., more than -25 hours and less than 26 hours); this allows easy support by implementations that already support the POSIX-required range [-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 pairs of four-byte values, written in network byte order; the first value of each pair gives the non-negative time (as returned by time(2)) at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the total number of leap seconds to be applied during the time period starting at the given time. The pairs of values are sorted in strictly ascending order by time. Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table's expiration time. Each leap second is at the end of a UTC calendar month. The first leap second has a non-negative occurrence time, and is a positive leap second if and only if its correction is positive; the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, or -1 for a negative leap second. If the leap second table is empty, the leap-second correction is zero for all timestamps; otherwise, for timestamps before the first occurrence time, the leap-second correction is zero if the first pair's correction is 1 or -1, and is unspecified otherwise (which can happen only in files truncated at the start).

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

The standard/wall and UT/local indicators were designed for transforming a TZif file's transition times into transitions appropriate for another time zone specified via a proleptic TZ string that lacks rules. For example, when TZ="EET-2EEST" and there is no TZif file "EET-2EEST", the idea was to adapt the transition times from a TZif file with the well-known name "posixrules" that is present only for this purpose and is a copy of the file "Europe/Brussels", a file with a different UT offset. POSIX does not specify the details of this obsolete transformational behavior, the default rules are installation-dependent, and no implementation is known to support this feature for timestamps past 2037, so users desiring (say) Greek time should instead specify TZ="Europe/Athens" for better historical coverage, falling back on TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" if POSIX conformance is required and older timestamps need not be handled accurately.

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
For version-2-format timezone files, the above header and data are followed by a second header and data, identical in format except that eight bytes are used for each transition time or leap second time. (Leap second counts remain four bytes.) After the second header and data comes a newline-enclosed string in the style of the contents of a proleptic TZ, for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The TZ string is empty (i.e., nothing between the newlines) if there is no proleptic representation for such instants. If non-empty, the TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string 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 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
For version-3-format timezone files, a TZ string (see newtzset(3)) may use the following POSIX.1-2024 extensions to POSIX.1-2017: First, as in TZ="<-02>2<-01>,M3.5.0/-1,M10.5.0/0", the hours part of its transition times may be signed and range from -167 through 167 instead of being limited to unsigned values from 0 through 24. Second, as in TZ="XXX3EDT4,0/0,J365/23", DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time.

  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
This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by older readers. The goals of this section are to help:

    •   TZif writers output files that avoid common pitfalls in older or buggy TZif readers,

    •   TZif readers avoid common pitfalls when reading files generated by future TZif writers, and

    •   any future specification authors see what sort of problems arise when the TZif format is changed.

When new versions of the TZif format have been defined, a design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate newer-version data useful even for older-version readers. This section attempts to document these compatibility issues and workarounds as well as documenting other common bugs in readers.

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) 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, for a time zone with a never-used standard time (XXX, -03) and negative daylight saving time (EDT, -04) all year. Alternatively, as a partial workaround, a writer can substitute standard time for the next time zone east – e.g., para el Tiempo Estándar Atlántico permanente (-04).

    •   Some readers designed for version 2 or 3 and that require strict conformance to RFC 9636 reject version 4 files whose leap second tables are truncated at the start or end in expiration times.

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

    •   Some readers mishandle timestamps before the first transition that has a timestamp that is not less than -2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 bits. As a partial workaround, a writer can output a dummy transition at timestamp -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.

    •   Some readers mishandle proleptic TZ strings that contain 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.

    •   Some readers may mishandle time zone abbreviations that contain fewer than 3 or more than 6 characters or that contain ASCII characters other than alphanumerics, 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. 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 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.

    •   Some readers generate ambiguous timestamps for positive leap seconds that occur when the UTC offset is not a multiple of 60 seconds. For example, with UTC offset +01:23:45 and a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they will map 78796815 to 01:23:59 instead of to 01:23:60. This has not yet been a practical problem, since no civil authority has observed such UTC offsets since leap seconds were introduced in 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.

    •   Some readers mishandle timestamps before the first transition that has a non-negative timestamp. Readers that do not support negative timestamps are likely to be more prone to this problem.

    •   Algunas aplicacines gestionan incorrectamente las abreviaturas de zona horaria como 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.

    •   Some readers mishandle UT offsets in the range [-3599, -1] seconds from UT because they integer-divide the offset by 3600 to get 0 and then display the hour part as

    •   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). October 2024. Internet RFC 9636 (https://www.rfc-editor.org/rfc/rfc9636) doi:10.17487/RFC9636 (https://doi.org/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 (https://www.gnu.org/licenses/gpl-3.0.html) 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.