La base de datos tz es una compilación colaborativa de información sobre las zonas horarias del mundo y las reglas para observar el horario de verano , destinada principalmente para su uso con programas informáticos y sistemas operativos. [2] Paul Eggert ha sido su editor y mantenedor desde 2005, [3] con el respaldo organizativo de ICANN . [4] La base de datos tz también se conoce como tzdata , la base de datos zoneinfo o la base de datos de zonas horarias de IANA (en honor a la Autoridad de Números Asignados de Internet ), y ocasionalmente como la base de datos Olson , en referencia al colaborador fundador, Arthur David Olson. [5]
Su convención de nombres uniforme para las entradas en la base de datos, como América/Nueva_York y Europa/París , fue diseñada por Paul Eggert. [6] La base de datos intenta registrar las zonas horarias históricas y todos los cambios civiles desde 1970, la época temporal de Unix . [7] También registra los segundos intercalares . [8]
La base de datos, así como algunos códigos fuente de referencia , son de dominio público . [9] Se publican nuevas ediciones de la base de datos y del código a medida que los cambios lo justifican, normalmente varias veces al año. [10]
En la base de datos tz, una zona horaria es cualquier región nacional en la que los relojes locales han coincidido desde 1970. [11] Esta definición se ocupa en primer lugar de las áreas geográficas que han tenido relojes locales coherentes. Una zona horaria es diferente de una región con una diferencia horaria estándar particular respecto de UTC , a la que a menudo se hace referencia como "zona horaria". Por lo tanto, cada una de las zonas horarias definidas por la base de datos tz puede utilizar múltiples diferencias respecto de UTC, como diferencias para la hora estándar y el horario de verano . [12]
La base de datos tz se publica como un conjunto de archivos de texto que enumeran las reglas y las transiciones de zona en un formato legible para humanos. Para su uso, estos archivos de texto se compilan en un conjunto de archivos binarios independientes de la plataforma (uno por zona horaria). El código fuente de referencia incluye un compilador llamado zic (compilador de información de zona), así como código para leer esos archivos y usarlos en API estándar como localtime()y mktime().
Cada zona horaria tiene una o más "líneas de zona" en uno de los archivos de texto de la base de datos tz. La primera línea de zona horaria de una zona horaria indica el nombre de la zona horaria; las líneas de zona posteriores para esa zona horaria dejan el nombre en blanco, lo que indica que se aplican a la misma zona que la línea anterior. Cada línea de zona de una zona especifica, para un rango de fecha y hora, la diferencia con respecto a UTC para la hora estándar, el nombre del conjunto de reglas que rigen el horario de verano (o un guion si siempre se aplica la hora estándar), el formato para las abreviaturas de zona horaria y, para todas las líneas de zona excepto la última, la fecha y hora en que finaliza el rango de fecha y hora regido por esa línea.
Las reglas para el horario de verano se especifican en conjuntos de reglas con nombre. Cada conjunto de reglas tiene una o más líneas de reglas en los archivos de texto. Una línea de regla contiene el nombre del conjunto de reglas al que pertenece, el primer año en el que se aplica la regla, el último año en el que se aplica la regla (o "solo" si se aplica solo en un año o "máximo" si es la regla vigente en ese momento), el tipo de año al que se aplica la regla ("-" si se aplica a todos los años en el rango especificado, lo que casi siempre es el caso; de lo contrario, un nombre utilizado como argumento para un script que indica si el año es del tipo especificado), el mes en el que la regla entra en vigor, el día en el que la regla entra en vigor (que podría ser un día específico o una especificación como "el último domingo del mes"), la hora del día en la que la regla entra en vigor, la cantidad de tiempo que se debe agregar al desfase con respecto a UTC cuando la regla está vigente y la letra o letras que se deben usar en la abreviatura de la zona horaria (por ejemplo, "S" si la regla rige el horario estándar y "D" si rige el horario de verano).
Las zonas horarias tienen nombres únicos en el formato " Área / Ubicación ", por ejemplo "América/Nueva_York". También se optó por utilizar nombres en inglés o equivalentes, y omitir la puntuación y los sufijos comunes. El carácter de subrayado se utiliza en lugar de espacios. Se utilizan guiones cuando aparecen en el nombre de una ubicación. Los nombres de Área y Ubicación tienen una longitud máxima de 14 caracteres. [13] [14]
Área es el nombre de un continente , un océano o "etc." Los continentes y océanos utilizados son África , América , Antártida , Ártico , Asia , Atlántico , Australia , Europa , Índico y Pacífico .
Se incluyen los océanos porque es difícil conectar algunas islas a un continente determinado. Algunas están conectadas geográficamente a un continente y políticamente a otro. Véase también Límites entre continentes .
El área especial de "Etc" se utiliza para algunas zonas administrativas, en particular para "Etc/UTC", que representa el Tiempo Universal Coordinado . Para cumplir con el estilo POSIX , los nombres de las zonas que comienzan con "Etc/GMT" tienen el signo invertido según la convención estándar ISO 8601. En el área "Etc", las zonas al oeste de GMT tienen un signo positivo y las del este tienen un signo negativo en su nombre (por ejemplo, "Etc/GMT-14" tiene 14 horas de adelanto respecto de GMT).
Ubicación es el nombre de un lugar específico dentro del área, generalmente una ciudad o una pequeña isla.
Los nombres de países no se utilizan normalmente en este esquema, principalmente porque no serían robustos, debido a los frecuentes cambios políticos y de fronteras. Los nombres de las grandes ciudades tienden a ser más permanentes. [15] Por lo general, se elige la ciudad más poblada de una región para representar toda la zona horaria, aunque se puede seleccionar otra ciudad si es más conocida, y se puede utilizar otra ubicación, incluida una ubicación que no sea una ciudad, si da como resultado un nombre menos ambiguo. [16] En el caso de que cambie el nombre de la ubicación utilizada para representar la zona horaria, la convención es crear un alias [17] en futuras ediciones para que tanto el nombre antiguo como el nuevo se refieran a la misma entrada de la base de datos.
En algunos casos, la ubicación se representa como un nombre compuesto, por ejemplo, la zona horaria "América/Indiana/Indianápolis". Los nombres de tres niveles incluyen los que aparecen en "América/Argentina/...", "América/Kentucky/...", "América/Indiana/..." y "América/Dakota_del_Norte/...".
La ubicación seleccionada es representativa de toda la zona. Sin embargo, si antes de 1970 existían diferencias dentro de la zona, las reglas de zona horaria solo se aplican en la ubicación indicada.
Estas son las líneas de reglas para las reglas estándar del horario de verano de los Estados Unidos, las líneas de reglas para las reglas del horario de verano vigentes en la zona horaria del este de los Estados Unidos (llamada "NYC" ya que la ciudad de Nueva York es la ciudad que representa esa zona) en algunos años, y las líneas de zona para la zona horaria de América/Nueva York, a partir de la versión de lanzamiento tzdata2011n de la base de datos de zonas horarias. Las líneas de zona y de reglas reflejan el historial del horario de verano en los Estados Unidos .
# Regla NOMBRE DESDE HASTA ESCRIBA EN EL EN GUARDAR LETRASRegla EE.UU. 1918 1919 - Mar Último dom 2:00 1:00 DRegla EE.UU. 1918 1919 - Oct últimoDom 2:00 0 SReglas de EE. UU. 1942 solamente - 9 de febrero 2:00 1:00 W # GuerraRegla US 1945 solamente - 14 de agosto 23:00u 1:00 P # PazRegla estadounidense de 1945 únicamente: 30 de septiembre a las 2:00 0 SRegla EE.UU. 1967 2006 - Oct últimodom 2:00 0 SRegla Estados Unidos 1967 1973 - Abr últimoDom 2:00 1:00 DRegla solo para EE. UU. de 1974: 6 de enero, 2:00 a 1:00 DReglas de EE. UU. de 1975 únicamente: 23 de febrero, 2:00 a 1:00 DRegla Estados Unidos 1976 1986 - Abr últimoDom 2:00 1:00 DRegla EE.UU. 1987 2006 - Abr Dom>=1 2:00 1:00 DRegla US 2007 máx. - Mar Dom>=8 2:00 1:00 DRegla EE.UU. 2007 máx. - Dom nov. >=1 2:00 0 S....# Regla NOMBRE DESDE HASTA ESCRIBA EN EL EN GUARDAR LETRARegla NYC 1920 solamente - Mar Último domingo 2:00 1:00 DRegla NYC 1920 solamente - Último domingo de octubre 2:00 0 SRegla NYC 1921 1966 - Abr últimoDom 2:00 1:00 DRegla NYC 1921 1954 - Sep últimoDom 2:00 0 SRegla NYC 1955 1966 - Oct últimodom 2:00 0 S# Zona NOMBRE GMTOFF REGLAS FORMATO [HASTA]Zona América/Nueva_York -4:56:02 - LMT 1883 18 de noviembre, 12:03:58 -5:00 hora del este de EE. UU. de 1920 -5:00 hora del este de Nueva York, 1942 -5:00 hora del este de EE. UU. de 1946 -5:00 hora del este de Nueva York, 1967 -5:00 hora del este de EE. UU.Para cada zona horaria que tenga múltiples diferencias horarias (normalmente debido al horario de verano), la base de datos tz registra el momento exacto de la transición. El formato también puede adaptarse a los cambios en las fechas y horas de las transiciones. Las zonas pueden tener cambios históricos en las reglas que se remontan a muchas décadas (como se muestra en el ejemplo anterior).
El archivo zone.tab es de dominio público y enumera las zonas. La ordenación de columnas y filas se describe en los comentarios del archivo, de la siguiente manera:
# Este archivo contiene una tabla con las siguientes columnas:# 1. Código de país de 2 caracteres ISO 3166. Consulte el archivo `iso3166.tab'.# 2. Latitud y longitud de la ubicación principal de la zona# en formato ISO 6709 signo-grados-minutos-segundos,# ya sea +-DDMM+-DDDMM o +-DDMMSS+-DDDMMSS,# primero latitud (+ es norte), luego longitud (+ es este).# 3. Nombre de zona utilizado en el valor de la variable de entorno TZ.# 4. Comentarios; presentes si y solo si el país tiene varias filas.# # Las columnas están separadas por una sola tabulación.# La tabla se ordena primero por país, luego un orden dentro del país que# (1) tiene cierto sentido geográfico, y# (2) coloca primero las zonas más pobladas, siempre que esto no contradiga (1).
Los datos anteriores a 1970 pretenden ser correctos para la ciudad que identifica la región, pero no necesariamente para toda la región. Esto se debe a que las nuevas regiones se crean solo cuando es necesario para distinguir los relojes desde 1970.
Por ejemplo, entre el 23 de octubre de 1963 y el 9 de diciembre de 1963, en Brasil solo los estados de Minas Gerais , Espirito Santo , Río de Janeiro y São Paulo tenían horario de verano. Sin embargo, en 2010 se rechazó una solicitud de separación de América/São Paulo con el argumento de que, desde 1970, los relojes eran los mismos en toda la región. [19]
La hora en Alemania , representada por Europa/Berlín , es incorrecta para el año 1945, cuando la Trizona utilizó reglas de horario de verano diferentes a las de Berlín. [20]
Hay dos zonas que cubren un área que estaba cubierta por dos países después de 1970. La base de datos sigue las definiciones de países según la norma ISO 3166-1 , cuyo predecesor, ISO 3166, se publicó por primera vez en 1974.
El código de referencia y la base de datos de tz son mantenidos por un grupo de voluntarios. Arthur David Olson realiza la mayoría de los cambios en el código de referencia de tz. Paul Eggert realiza la mayoría de los cambios en la base de datos de tz. Los cambios propuestos se envían a la lista de correo de tz, que está conectada al grupo de noticias de Usenet comp.time.tz. Los archivos fuente se distribuyen a través del servidor FTP de IANA. Normalmente, estos archivos son tomados por un distribuidor de software como Debian , compilados y luego el código fuente y los binarios se empaquetan como parte de esa distribución. Los usuarios finales pueden confiar en los procedimientos de actualización de su distribución de software, lo que puede implicar algún retraso, u obtener el código fuente directamente y crear los archivos binarios ellos mismos. El IETF ha publicado RFC 6557, "Procedimientos para mantener la base de datos de zonas horarias" que documenta las mejores prácticas basadas en principios similares.
La ruta estándar para la base de datos de zonas horarias se encuentra /usr/share/zoneinfo/en las distribuciones de Linux, macOS y algunos otros sistemas similares a Unix .
Los límites geográficos en forma de conjuntos de coordenadas no son parte de la base de datos tz, pero los límites son publicados por Evan Siroky [1] en formatos GeoJSON y shapefile .
El repositorio de datos locales comunes Unicode (CLDR) hace referencia a las zonas de la base de datos tz. Sin embargo, como el nombre de una zona puede cambiar de una versión de la base de datos tz a otra, el CLDR asigna el código UN/LOCODE de la ciudad utilizada en el nombre de la zona, o un código asignado internamente si no existe dicha ciudad para la zona, a una zona tzdb. [21] [22]
La base de datos tz se utiliza para el procesamiento y la conversión de zonas horarias en muchos sistemas de software informático, incluidos:
std::chrono::tzdb ;Los identificadores de zona horaria de Olson también son utilizados por el Repositorio de datos de configuración regional común de Unicode (CLDR) y los Componentes internacionales para Unicode (ICU). Por ejemplo, la tabla CLDR Windows–Tzid asigna los identificadores de zona horaria de Microsoft Windows a los nombres estándar de Olson, aunque dicha asignación no puede ser perfecta porque la cantidad de zonas horarias en los sistemas Windows es significativamente menor que en la base de datos TZ de IANA. [33]
Los orígenes del proyecto se remontan a 1986 o antes. [34]
El 30 de septiembre de 2011, se presentó una demanda, Astrolabe, Inc. v. Olson et al. , relacionada con los derechos de autor de la base de datos. [35] [36] Como resultado, el 6 de octubre de 2011, la lista de correo y el sitio FTP de la base de datos fueron cerrados. [37] El caso giraba en torno al uso por parte de los mantenedores de la base de datos de The American Atlas , de Thomas G. Shanks , y The International Atlas , de Thomas G. Shanks y Rique Pottenger. Se quejaba de la reproducción no autorizada de datos del atlas en el archivo de la lista de correo de zonas horarias y en algunas colecciones de enlaces auxiliares mantenidas con la base de datos, aunque en realidad no apuntaba a la base de datos en sí. La queja se relacionaba únicamente con la compilación de datos históricos de zonas horarias, y no cubría las tablas de zonas horarias mundiales de tzdata existentes. [36] [38] [39]
Esta demanda se resolvió el 22 de febrero de 2012 después de la intervención de la Electronic Frontier Foundation , cuando Astrolabe solicitó voluntariamente desestimar la demanda sin haber notificado nunca a los demandados y aceptó un pacto de no demandar en el futuro. [40]
La ICANN asumió la responsabilidad del mantenimiento de la base de datos el 14 de octubre de 2011. [4] La base de datos completa y una descripción de los planes para su mantenimiento están disponibles en línea en IANA . [41]
Cada zona horaria corresponde típicamente a una región geográfica que es más pequeña que una zona horaria tradicional, porque los relojes en una zona horaria coinciden todos después de 1970, mientras que una zona horaria tradicional simplemente especifica la hora estándar actual. Por ejemplo, las aplicaciones que tratan con marcas de tiempo actuales y futuras en la zona horaria tradicional de montaña de América del Norte pueden elegir entre las zonas horarias América/Denver que observa el horario de verano (DST) al estilo de EE. UU., y América/Phoenix que no observa el DST. Las aplicaciones que también tratan con marcas de tiempo pasadas en la zona horaria de montaña pueden elegir entre más de una docena de zonas horarias, como América/Boise, América/Edmonton y América/Hermosillo, cada una de las cuales actualmente usa la hora de montaña pero difiere de otras zonas horarias para algunas marcas de tiempo posteriores a 1970.
Utilice solo componentes de nombre de archivo POSIX válidos (es decir, las partes de los nombres que no sean '/'). No utilice los componentes de nombre de archivo '.' y '..'. Dentro de un componente de nombre de archivo, utilice solo letras ASCII, '.', '-' y '_'. No utilice dígitos, ya que eso podría crear una ambigüedad con las cadenas POSIX TZ. Un componente de nombre de archivo no debe superar los 14 caracteres ni comenzar con '-'. Por ejemplo, prefiera Asia/Brunei a Asia/Bandar_Seri_Begawan. Excepciones: consulte la discusión de nombres heredados a continuación.
Mantenga las ubicaciones compactas. Utilice ciudades o islas pequeñas, no países o regiones, de modo que los cambios futuros no dividan las ubicaciones individuales en diferentes zonas horarias. Por ejemplo, prefiera Europa/París a Europa/Francia, ya que Francia ha tenido múltiples zonas horarias.
Estas son las pautas generales que se utilizan para elegir los nombres de las zonas horarias, en orden decreciente de importancia: ... Si un nombre es ambiguo, use una alternativa menos ambigua; p. ej., muchas ciudades se llaman San José y Georgetown, por lo que se prefiere América/Costa_Rica a América/San_José y América/Guyana a América/Georgetown. ... Use la ubicación más poblada de una región, p. ej., prefiera Asia/Shanghái a Asia/Pekín. Entre las ubicaciones con poblaciones similares, elija la ubicación más conocida, p. ej., prefiera Europa/Roma a Europa/Milán.
Esto significa que la ortografía anterior seguirá funcionando. Por lo general, un cambio de nombre debería ocurrir solo en el caso poco frecuente de que cambie la ortografía consensuada en inglés de una ubicación; por ejemplo, en 2008, Asia/Calcutta pasó a llamarse Asia/Kolkata debido al uso generalizado durante mucho tiempo del nuevo nombre de la ciudad en lugar del antiguo.
Su forma canónica es el nombre de zona correspondiente en mayúsculas y minúsculas utilizado en la base de datos de zonas horarias de la IANA. ... Se recomienda que las implementaciones utilicen la información de zona horaria de la base de datos de zonas horarias de la IANA.