archivos tz(5) File Formats Manual archivos tz(5) NOMBRE archivos tz - informacion de zona horaria DESCRIPCION Los archivos de informacion 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 mas 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 representara 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: o La secuencia magica ASCII de cuatro bytes "TZif" identifica el archivo como un archivo de informacion de zona horaria. o Un byte que identifica la version del formato del archivo (a partir de 2021, ya sea ASCII NUL, "2", "3", o "4"). o Quince bytes de ceros, reservando el espacio para algun uso futuro. o Seis valores enteros de cuatro bytes, en el siguiente orden: tzh_ttisutcnt Numero de indicadores UT/locales almacenados en el archivo. (UT es hora universal). tzh_ttisstdcnt Cantidad de indicadores estandar/pared almacenados en el fichero. tzh_leapcnt Cantidad de segundos durante los cuales se almacenan las entradas de datos en el archivo. tzh_timecnt Cantidad de tiempos de transicion 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: o 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 transicion (tal como retorna time(2)) en el que cambian las reglas para calcular la hora local. o tzh_timecnt valores enteros sin signo de un byte. Cada uno de ellos, excepto el ultimo, indica cual de los diferentes tipos de hora local descritos en el archivo esta asociado con el periodo de tiempo que comienza con el mismo tiempo de transicion indexado y continua hasta el siguiente tiempo de transicion, pero sin incluirlo. El ultimo tipo de hora esta presente solo para verificar la coherencia con la cadena TZ de estilo POSIX.1-2017 que se describe a continuacion. Estos valores serviran como indices en el siguiente campo. o 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 escribira como un valor entero de cuatro bytes con signo para tt_utoff, en orden de bytes segun 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 dara el numero de segundos que se agregaran a UT, tt_isdst indica si tm_isdst debe establecerse mediante localtime(3) y tt_desigidx es el indice en el vector de bytes de abreviatura de zona horaria que van despues de las entradas ttinfo en el archivo. Si la cadena designada es '-00', la entrada ttinfo es un marcador de posicion que indica que la hora local no esta definida. El valor tt_utoff nunca es igual a -2**31, para permitir que los clientes de 32 bits lo nieguen sin dar error. Ademas, en aplicaciones en productivo tt_utoff esta en el intervalo [-89999, 93599] (es decir, mas 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]. o 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 codificacion de estas cadenas. o 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 (segun 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 correccion, que es el numero total de segundos intercalares que se aplicaran durante el periodo 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 ultimo par tiene la misma correccion que el anterior, el ultimo 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 aparicion no negativo y es un segundo intercalar positivo si y solo si su correccion es positiva; la correccion para cada segundo intercalar despues 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 esta vacia, la correccion 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 aparicion, la correccion del segundo intercalar es cero si la correccion del primer par es 1 o -1, y en caso contrario no se especifica (lo que solo puede ocurrir en archivos truncados al inicio). o tzh_ttisstdcnt indicadores estandar/pared, cada uno almacenado como un byte booleano; ellos dicen si los tiempos de transicion asociados con los tipos de tiempo local fueron especificados como tiempo estandar o local (hora del reloj de pared). o tzh_ttisutcnt Indicadores UT/locales. Cada uno almacenado como un byte booleano, indicaran si los tiempos de transicion asociados con los tipos de tiempo locales se definieron como UT o tiempo local. Si se establece un indicador UT/local, tambien debe establecerse el indicador estandar/pared correspondiente. Los indicadores estandar/pared y UT/local fueron disenados para transformar los tiempos de transicion de un archivo TZif en transiciones apropiadas para otra zona horaria especificada a traves de una cadena TZ al estilo POSIX.1-2017 que carece de reglas. Por ejemplo, cuando TZ='EET-2EEST' y no hay archivo TZif ' EET *-2EAST', la idea era adaptar los tiempos de transicion de un archivo de TZIF con el conocido nombre 'posixrules' que esta presente solo para este proposito y es una copia del archivo 'Europe/Brussels', archivo con un espaciado UT diferente. POSIX no define este comportamiento de transformacion obsoleto, las reglas predeterminadas son dependientes del sistema, y no se conoce ninguna implementacion que soporte esta caracteristica para marcas de tiempo mas alla de 2037, por lo que los usuarios que deseen (por ejemplo) hora griega deberan indicar TZ='Europa/Atenas' para mayor seguridad, volviendo a TZ='EET-2EEST,M3.5.0/3,M10.5.0/4' si se requiere conformidad con POSIX y no necesita manejar con precision las marcas de tiempo antiguas. La funcion 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 transicion registrado en el archivo. Formato de la version 2 Para los archivos de zona horaria de esta segunda version del formato, al encabezado y los datos anteriores le sigue un segundo encabezamiento y datos, identicos en formato, salvo que se usan ocho bytes para cada tiempo de transicion o segundo intercalar. Se siguen disponiendo de 4 bytes para el recuento de segundos intercalares.Despues del segundo encabezado y de los datos viene una cadena encerrada entre nuevas lineas al estilo del contenido de una variable de entorno POSIX.1-2017 TZ, para usar en el manejo de instantes despues del ultimo tiempo de transicion almacenado en el archivo o para todos los instantes si el arquivo no tiene transiciones. La cadena TZ estara vacia (es decir, no hay nada entre las nuevas lineas) si no hay representacion en el estilo POSIX.1-2017 para esos instantes. Si no esta vacio, la cadena TZ debe coincidir con el tipo de tiempo local despues del ultimo tiempo de transicion si esta presente en los datos de ocho bytes; por ejemplo, dada la cadena "WET0WEST,M3.5.0/1,M10.5.0" entonces si el ultimo tiempo de transicion es en julio, el tipo de tiempo local de la transicion debe definir un tiempo de cambio de hora verano/invierno abreviado "WEST" es una hora al este de UT. Tambien, si hay al menos una transicion, el tipo de tiempo 0 se asocia con el periodo de tiempo desde el pasado indefinido hasta, pero no inclusive, el primer tiempo de transicion. Formato de version 3 Para archivos de zona horaria de formato de version 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 transicion pueden tener signo y varian entre -167 y 167 en lugar de los valores requeridos por POSIX (entre 0 y 24). En segundo lugar, el horario de verano esta en vigor durante todo el ano si comienza el 1 de enero a las 00:00 y termina el 31 de diciembre a las 24:00, mas la diferencia entre el horario de verano y la hora estandar. Formato de version 4 Para los archivos TZif en la version 4 del formato, el primer segundo intercalar puede tener una correccion distinta de +1 y de -1, para representar la particion al inicio del archivo TZIF. Asimismo, si hay dos o mas transiciones de segundo intercalar y la correccion de la ultima entrada es igual a la anterior, la entrada ultima denota la expiracion de la tabla de segundos intercalares en lugar de denotar la de un segundo intercalar. Las marcas de tiempo despues de esta expiracion son poco fiables y es probable que se anadan entradas de segundos intercalares despues de dicho expirado, que cambiaran la forma en que se tratan las marcas de tiempo posteriores a ese instante. Consideraciones de interoperabilidad Los futuros cambios en el formato pueden anadir mas datos. Los archivos de la version 1 se consideran obsoletos y no deben emplearse. No admiten tiempos de transicion despues del ano 2038. Las aplicaciones que solo entienden la version 1 deben ignorar cualquier dato que se extienda mas alla del final del bloque de datos de la version 1. Aparte de la version 1, las aplicaciones que cree estos archivos deben generar el numero de version mas bajo necesario para trabajar con los datos de un archivo. Por ejemplo, se debe generar un archivo de version 4 solo si su tabla de segundos intercalares expira o se trunco al inicio. Una aplicacion que no genera un archivo de version 4 deberia generar un archivos de version 3 solo si las extensiones de cadenas TZ son necesarias para gestionar con precision los tiempos de transicion. La secuencia de cambios de hora definida por el encabezado de la version 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 guia ayuda a las aplicaciones que utilicen la (obsoleta) version 1 para que hagan la misma interpretacion de las marcas de tiempos dentro de la subsecuencia contigua. Tambien permite, a las aplicaciones que generan estos archivos y que no consideran a los lectores mas antiguos, usar un tzh_timecnt de cero en el bloque de datos de la version 1 para ahorrar espacio. Cuando un archivo TZif indica la fecha de caducidad de la tabla de segundos intercalares, los lectores de TZIF no deberian procesar marcas de tiempo posteriores a esta fecha, o procesarlos como si no existiera esta fecha de caducidad incluso indicandolo con un mensaje de error. Las designaciones de zona horaria deberan consistir en al menos tres (3) y no mas de seis (6) caracteres ASCII alfanumericos, "-", y "+". Para preservar la compatibilidad con los requisitos de POSIX para las abreviaturas de zonas horarias. Al leer un archivo de version 2 o superior, se debera ignorar el encabezado de la version 1 y el bloque de datos, simplemente saltandolos. Las aplicaciones que lean estos archivos debaran calcular las longitudes totales de los encabezados y bloques de datos y comprobar que todos ellos se ajustan dentro del tamano real del archivo, como parte de la verificacion de la validez del archivo. Cuando debe introducirse un segundo de intercalacion, las aplicaciones deben anadir un segundo adicional al minuto local que contiene el segundo justo antes de dicho segundo de intercalacion. Si esto ocurre cuando el desvio UTC no es un multiplo de 60 segundos, el segundo de intercalacion se introduce antes que el ultimo segundo del minuto local y los segundos locales restantes del minuto se numeran a traves de 60 en lugar de 59 que seria lo habitual. No afecta al desplazamiento UTC. Cuestiones comunes de interoperabilidad En esta seccion se detallan problemas comunes al leer o escribir archivos TZif. La mayoria suelen ser ocurrir durante la generacion de archivos TZif para el uso de las aplicaciones mas antiguas. Los objetivos de esta seccion son: o ayudar a los creadores de archivos TZif a crear archivos que eviten los errores mas habituales en lectores TZIF mas antiguos o con mal implementados, o para ayudar a las aplicaciones que lean archivos TZif a evitar los errores mas comunes al leer los archivos generados por futuras aplicaciones y o 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 version posterior para la que el lector fue disenado. 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 disenadas para interpretar versiones mas antiguas. Esta seccion intenta documentar estosproblemas de compatibilidad aportando soluciones, asi como documentar otros errores comunes en la interpretacion que las aplicaciones hacen de estos archivos. Los problemas de interoperabilidad con TZif incluyen los siguientes: o Algunas aplicaciones examinan solo los datos de la version 1. Como solucion parcial, las aplicaciones que crean archivos TZif pueden sacar tantos datos de la version 1 como sea posible. Sin embargo, al leerse deberan ignorarse los datos de la version 1, y debe usar los datos en la version 2+, incluso si los timestamps nativos del lector solo tienen 32 bits. o Algunos lectores disenados para la version 2 pueden manipular mal los timestamps despues de la ultima transicion de un archivo de la version 3 o superior, porque no pueden analizar las extensiones de POSIX.1-2017 en la cadena similar a TZ. Como solucion parcial, pueden producirse mas transiciones de las necesarias, de modo que solo los lectores de la version 2 manipulen incorrectamente las marcas de tiempo del futuro. o Algunos lectores disenados para la version 2 no permiten tener el horario de verano con transiciones despues de las 24:00 - por ejemplo, una cadena TZ) "EST5EDT,0/0,J365/25" Indicando el horario de verano del este permanente (-04). Como solucion, puede sustituirse el tiempo estandar por dos zonas horarias al este, por ejemplo, "XXX3EDT4,0/0,J365/23" para una zona horaria con un tiempo estandar nunca utilizado (XXX, -03) y horario de verano negativo (EDT, -04), durante todo el ano. Alternativamente, como una solucion parcial puede sustituirse el tiempo estandar para la proxima zona horario al este - e.g., "AST4" para el Tiempo Estandar Atlantico permanente (-04). o Algunas aplicaciones disenadas para la version 2 o 3 requieren una estricta conformidad con RFC 8536 y por tanto rechazan los archivos de la version 4 cuyas tablas de segundos intercalares estan truncadas al comienzo o que terminan en tiempos de caducidad. o 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 ultima transicion. Como solucion parcial, pueden producirse mas transiciones de las necesarias. o Algunos lectores no usan el tipo de tiempo 0 para las marcas de tiempo antes de la primera transicion, sino que que deducen un tipo de tiempo de forma heuristica y no siempre se selecciona el tiempo tipo 0. Como solucion parcial, puede simularse una primera transicion en los inicios. o Algunas aplicaciones que leer estos archivos, gestionan mal las marcas de tiempo antes de la primera transicion que tiene una marca de tiempo no inferior a -2**31. Las que soportan solo marcas de tiempo de 32 bits probablemente sean mas propensas a este problema, por ejemplo, al procesar transiciones de 64 bits porque solo algunas son representables en 32 bits. Como solucion parcial, puede emitir una transicion en la marca -2**31 aunque no es lo ideal. o Algunas aplicaciones gestionan mal una transicion si su marca de tiempo tiene el valor minimo posible de 64 bits con signo. No se recomiendan marcas de tiempo inferiores a -2**59. o Algunas aplicaciones manejan incorrectamente las cadenas TZ que contienen "<" o ">". Como solucion parcial, puede evitarse el uso "<" o ">" para abreviaturas de zona horaria que contienen solo caracteres alfabeticos. o Muchas aplicaciones gestionan incorrectamente las abreviaturas de zonas horarias que contienen caracteres que no ASCII por lo que no se recomienda su uso. o Algunas aplicaciones pueden gestionar mal las abreviaturas de zona horaria que contienen menos de 3 o mas de 6 caracteres, o que contienen caracteres ASCII no alfanumericos. "-", y "+". No se recomienda el uso de estas abreviaturas. o Algunas aplicaciones manejan mal los archivos TZif que especifican compensaciones UT del horario de verano inferiores a las compensaciones UT para la hora estandar 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 estandar (IST, +01) en verano y el horario de verano (GMT, +00) en invierno. Como solucion parcial, un escritor puede generar datos para el equivalente de la cadena TZ "GMT0IST,M3.5.0/1,M10.5.0", intercambiando asi entre el horario estandar y el horario de verano. Aunque esta solucion identifica erroneamente la parte del ano que utiliza el horario de verano, si registra correctamente las compensaciones UT y las abreviaturas de zona horaria. o Algunos lectores generan marcas de tiempo ambiguas para segundos intercalares positivos que ocurren cuando el desplazamiento UTC no es multiplo 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 asignaran tanto 78796800 como 78796801 a las 01:23:45 hora local al dia siguiente en lugar de asignar este ultimo a las 01:23:46, y asignaran 78796815 a las 01:23:59 en lugar de a las 01:23:60. Esto todavia no ha sido un problema practico, ya que ninguna autoridad civil ha observado tales compensaciones UTC desde que se introdujeron los segundos intercalares en 1972. A continuacion, se enumeran algunos problemas de interoperabilidad principalmente como advertencias para los desarrolladores de aplicaciones que lean estos archivos. o Algunas aplicaciones no admiten marcas de tiempo negativas. Los desarrolladores deberian tener esto en cuenta si necesitan trabajar con datos anteriores a 1970. o Algunos lectores manejan mal las marcas de tiempo antes de la primera transicion que tiene una marca de tiempo no negativa. Es probable que los lectores que no admitan marcas de tiempo negativas sean mas propensos a sufrir este problema. o Algunas aplicacines gestionan incorrectamente las abreviaturas de zona horaria como "-08" que contienen "+", "-", o digitos. o Algunos lectores manejan mal las compensaciones UT que estan fuera del intervalo tradicional de -12 a +12 horas. Por ejemplo, no admiten ubicaciones como Kiritimati al estar fuera de este intervalo. o Algunas aplicaciones gestionan incorrectamente las compensaciones UT en el intervalo [-3599, -1] segundos desde UT, porque dividen la compensacion en numeros enteros entre 3600 para obtener 0 y luego muestran la parte horaria como "+00". o Algunas aplicaciones gestionan incorrectamente las compensaciones UT que no son multiplos de una hora, de 15 minutos o de 1 minuto. VEASE TAMBIEN time(2), localtime(3), tzset(3), tzselect(8), zdump(8), zic(8). Olson A, Eggert P, Murchison K. El formato de informacion de zona horaria (TZif). 2019 febrero Internet RFC 8536 doi:10.17487/RFC8536 . TRADUCCION La traduccion al espanol de esta pagina del manual fue creada por Juan Piernas y Marcos Fouces Esta traduccion es documentacion libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. Si encuentra algun error en la traduccion de esta pagina del manual, envie un correo electronico a . Base de Datos de Zonas Horarias archivos tz(5)