tzfile(5) File Formats Manual tzfile(5) NOM tzfile - Informations de zone horaire DESCRIPTION Les fichiers d'informations de zone horaire utilises par tzset(3) sont classiquement trouves sous un repertoire avec un nom tel que /usr/share/zoneinfo. Ces fichiers utilisent le format decrit dans la RFC 9636 a propos d'Internet. Chaque fichier est une sequence d'octets. Dans un fichier, un entier binaire est represente par une sequence de un ou plusieurs octets dans l'ordre du reseau (gros boutiste ou octets de poids le plus fort en premier) avec tous les bits significatifs, un entier binaire signe est represente en utilisant deux complements et un booleen est represente par un entier binaire d'un octet qui est soit 0 (faux) ou 1 (vrai). Le format commence par un en-tete de 44 octets contenant les champs suivants : - la sequence magique ASCII de quatre octets "TZif" identifiant le fichier comme un fichier d'information de zone horaire ; - un octet identifiant la version du format de fichier et (a partir de 2021), un NUL ASCII, "2", "3", ou "4"). - quinze octets contenant des zeros, reserves pour une utilisation future ; - six valeurs d'entier composees de quatre octets, dans l'ordre suivant : tzh_ttisutcnt le nombre d'indicateurs TU/locaux enregistres dans le fichier (TU est le temps universel), tzh_ttisstdcnt le nombre d'indicateurs standard/locaux enregistres dans le fichier, tzh_leapcnt le nombre de secondes intercalaires pour lesquelles des donnees sont enregistrees dans le fichier, tzh_timecnt le nombre d'instants de transition pour lesquels des donnees sont enregistrees dans le fichier, tzh_typecnt le nombre de types d'heure locale pour lesquels des donnees sont enregistrees dans le fichier (ne doit pas etre zero), tzh_charcnt le nombre d'octets de chaines d'abreviation de zone horaire enregistrees dans le fichier. L'en-tete ci-dessus est suivi des champs ci-apres dont la longueur depend du contenu de l'en-tete : - tzh_timecnt Valeurs sous forme d'entier signe de quatre octets, triees dans l'ordre ascendant. Ces valeurs sont ecrites dans l'ordre d'octets du reseau. Chacune est utilisee comme instant de transition (tel que renvoye par time(2)) quand les regles de calcul de l'heure locale changent ; - tzh_timecnt Valeurs sous forme d'entier non signe d'un octet. Chacune, sauf la derniere, indique lequel des differents types d'heure locale decrits dans le fichier est associe avec la periode de temps debutant avec l'instant de transition indexe de maniere identique et continuant jusqu'au prochain instant de transition (non inclus). Le dernier type de temps est present uniquement pour des raisons de verification coherente avec la chaine TZ proleptique decrite ci-apres. Ces valeurs servent d'indices dans le champ suivant ; - tzh_typecnt Entrees ttinfo, chacune definie comme suit : struct ttinfo { int32_t tt_utoff; unsigned char tt_isdst; unsigned char tt_desigidx; }; Chaque structure est ecrite comme valeur sous forme d'entier de quatre octets pour tt_utoff, dans l'ordre des octets du reseau, suivi d'un booleen d'un octet pour tt_isdst et une valeur d'un octet pour tt_desigidx. Dans chaque structure, tt_utoff donne le nombre de secondes a ajouter au temps universel, tt_isdst indique si tm_isdst doit etre regle par localtime(3) et tt_desigidx sert d'indice dans le tableau des octets d'abreviation de zone horaire qui suivent les entrees ttinfo dans le fichier. Si la chaine designee est << -00 >>, l'entree ttinfo est un parametre fictif indiquant que l'heure locale n'est pas precisee. La valeur tt_utoff n'est jamais egale a -2**31 pour permettre au clients 32 bits de l'indiquer sans erreur d'operande. Aussi, dans les applications reelles, tt_utoff se situe dans l'intervalle [-89999, 93599] (c'est-a-dire plus de -25 heures et moins de 26 heures). Cela permet une prise en charge facile par les implementations qui gerent deja l'intervalle requis par POSIX [-24:59:59, 25:59:59] ; - tzh_charcnt Octets representant des designations de zone horaire, qui sont des chaines terminees par un octet NULL, chacune indicee par les valeurs tt_desigidx mentionnees ci-dessus et correspondant a une abreviation de zone horaire. Les chaines d'octets peuvent se chevaucher si une est un suffixe de l'autre. L'encodage de ces chaines n'est pas precise ; - tzh_leapcnt Paires de valeurs composees de quatre octets ecrits dans l'ordre des octets du reseau. La premiere valeur de chaque paire donne le temps non negatif (tel que renvoye par time(2)) auquel les secondes intercalaires sont inserees ou le moment ou la table de secondes intercalaires expire. La seconde valeur est un entier signe indiquant la correction qui est le nombre total de secondes intercalaires a inserer durant la periode de temps debutant au temps indique. Les paires de valeurs sont ordonnees strictement selon le temps. Chaque paire indique une seconde intercalaire soit positive soit negative, excepte que si la derniere paire a la meme correction que la precedente, la derniere paire indique l'instant d'expiration de la table de secondes intercalaires. Chaque seconde intercalaire se produit a la fin d'un mois calendaire du temps universel coordonne (UTC). La premiere seconde intercalaire a un temps d'occurrence non negatif et est une seconde intercalaire positive que si, et uniquement si, sa correction est positive. La correction pour chaque seconde intercalaire apres la premiere differe de la seconde intercalaire precedente de 1 pour une seconde intercalaire positive ou de -1 pour une seconde intercalaire negative. Si la table de secondes intercalaires est vide, la correction de seconde intercalaire est zero pour tous les horodatages. Sinon, pour les horodatages avant le temps de la premiere occurrence, la correction de seconde intercalaire est zero si la premiere correction de paire est 1 ou -1, et est autrement non precisee (ce qui peut se produire seulement dans des fichiers tronques au demarrage) ; - tzh_ttisstdcnt Indicateurs standard/locaux, chacun stocke sous forme de booleen d'un octet. Ils indiquent si les instants de transition associes avec les types de temps local ont ete indiques comme temps standard ou comme temps local (horloge murale) ; - tzh_ttisutcnt Indicateurs TU/locaux, chacun stocke sous forme de booleen d'un octet. Ils indiquent si les instants de transition associes avec les types de temps local ont ete indiques comme temps universel ou comme temps local. Si un indicateur TU/local est defini, l'indicateur standard/local correspondant doit aussi etre defini. Les indicateurs standard/local et TU/local ont ete concus pour transformer les instants de transition de fichier TZif en transitions appropriees pour une autre zone horaire specifiee a l'aide d'une chaine TZ proleptique n'ayant pas de regles. Par exemple, quand TZ="EET-2EEST" et qu'il n'y a pas de fichier TZif << EET-2EEST >>, l'idee etait d'adapter les instants de transition d'un TZif avec le nom tres connu << posixrules >> qui existe uniquement dans ce but et qui est une copie du fichier << Europe/Brussels >>, un fichier avec un decalage de temps universel different. POSIX n'indique pas les details de ce comportement obsolete de transformation, les regles par defaut dependent de l'installation et aucune implementation n'est connue pour prendre en charge cette fonctionnalite pour les horodatages apres 2037, aussi les utilisateurs desirant par exemple l'heure grecque doivent plutot preciser TZ="Europe/Athens" pour une meilleure couverture historique, revenant a TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" si une conformite a POSIX est necessaire et que les anciens horodatages n'ont pas besoin d'etre geres de maniere precise. La fonction Localtime(3) utilise normalement la premiere structure ttinfo dans le fichier si soit tzh_timecnt est zero ou si son parametre horaire est anterieur au premier instant de transition enregistre dans le fichier. Format version 2 Pour les fichiers de zone horaire dans le format 2, l'en-tete et les donnees ci-dessus sont suivies d'un second en-tete et de donnees, identiques en format sauf que huit octets sont utilises pour chaque instant de transition ou de secondes intercalaires (le compte de secondes intercalaires est toujours de quatre octets). Apres le deuxieme en-tete et les donnees, vient une chaine, entouree de sauts de lignes, du style du contenu d'une zone horaire proleptique, utilisee pour gerer les instants apres le dernier instant de transition stocke dans le fichier ou pour tous les instants si le fichier n'a pas de transition. La chaine TZ est vide (c'est-a-dire rien entre les deux sauts de ligne) s'il n'existe pas de representation proleptique pour de tels instants. Si elle n'est pas vide, la chaine TZ doit etre en accord avec le type d'heure locale apres le dernier instant de transition, si present dans les donnees de huit octets ; par exemple, soit la chaine "WET0WEST,M3.5.0/1,M10.5.0" est indiquee, alors si le dernier instant de transition est en juillet, le type d'heure locale de la transition doit indiquer une heure d'ete abregee en "WEST" c'est-a-dire une heure a l'est du temps universel. La chaine TZ peut contenir des abreviations de zone horaire et des decalages par rapport au temps universel qui n'apparaissent nulle part ailleurs dans le fichier TZif. Aussi, s'il y a au moins un instant de transition, le type de temps 0 est associe a la periode de temps d'un passe illimite jusqu'au, mais sans l'inclure, tout premier instant de transition. Format version 3 Pour les fichiers de zone horaire de format version 3, une chaine TZ (voir newtzset(3)) peut utiliser les extensions POSIX.1-2024 suivantes a POSIX.1-2017 : d'abord, comme dans TZ="<-02>2<-01>,M3.5.0/-1,M10.5.0/0", la partie heure peut etre signee et aller de -167 jusqu'a 167 au lieu d'etre limitee a des valeurs non signees allant de 0 a 24. Deuxiemement, comme dans TZ="XXX3EDT4,0/0,J365/23", l'heure d'ete est effective toute l'annee si elle commence le premier janvier a 00:00 et se termine le 31 decembre a 24:00 plus la difference entre le temps d'heure d'ete et le temps standard. Format version 4 Pour les fichiers TZif de format version 4, le premier enregistrement de seconde intercalaire peut avoir une correction qui n'est ni +1 ni -1, pour representer la troncature du fichier TZif au demarrage. Aussi, si deux ou plus transitions de seconde intercalaire sont presentes et que la correction de la derniere entree egale celle qui la precede, la derniere entree indique l'expiration de la table de secondes intercalaires au lieu d'une seconde intercalaire. Les horodatages apres cette expiration ne sont pas fiables par le fait que de prochaines publications ajouteront probablement des entrees de seconde intercalaire apres l'expiration, et que les secondes intercalaires ajoutees changeront la facon dont les horodatages post-expiration seront traites. Considerations d'interoperabilite Des changements futurs au format pourront ajouter plus de donnees. Les fichiers de format version 1 sont consideres comme etant d'un format patrimonial et ne devraient plus etre crees, puisqu'ils ne prennent pas en charge les instants de transition apres l'annee 2038. Les lecteurs qui ne comprennent que la version 1 doivent ignorer toute donnee allant au-dela de la fin estimee de blocs de donnees version 1. Autrement que pour la version 1, les ecrivains devraient generer le numero de version le plus petit necessaire pour les donnees d'un fichier. Par exemple, un ecrivain devrait creer un fichier de version 4 seulement si sa table de secondes intercalaires expire ou est tronquee au demarrage. De la meme facon, un ecrivain ne creant pas un fichier de version 4 devrait creer un fichier de version 3 seulement si les extensions de chaine TZ sont necessaires pour modeler precisement les instants de transition. La sequence de modifications de temps definie par l'en-tete et le bloc de donnees version 1 devrait etre une sous-sequence contigue des modifications de temps definies par l'en-tete et le bloc de donnees version 2+ et par le pied de page. Ces recommandations aident les ecrivains obsolescents de version 1 a s'accorder avec les ecrivains actuels a partir des horodatages dans la sous-sequence contigue. Elles permettent aussi aux ecrivains ne gerant pas les ecrivains obsolescents d'utiliser un tzh_timecnt de zero dans le bloc de donnees version 1 pour economiser de l'espace. Quand un fichier TZif contient une date d'expiration de table de secondes intercalaires, les ecrivains de TZif devraient soit refuser de traiter les horodatages post-expiration ou les traiter comme si la date d'expiration n'existait pas (possiblement avec une indication d'erreur). Les abreviations de zone horaire devraient consister a au moins trois (3) et pas plus de six (6) caracteres ASCII de l'ensemble alphanumerique, "-", et "+". Cela doit l'etre pour une compatibilite avec les exigences de POSIX pour l'abreviation des zones horaires. Une abreviation de zone horaire numerique doit correspondre au decalage par rapport au temps universel. Par exemple, << +0530 >> ne pourra etre utilise que si le decalage par rapport au temps universel est de 5,5 heures en avance, et << -00 >> uniquement si le decalage est nul. Lors de la lecture d'un fichier de version 2 ou superieure, les lecteurs devraient ignorer l'en-tete et le bloc de donnees version 1 sauf pour les omettre. Les lecteurs devraient integrer le calcul des longueurs totales des en-tetes et des blocs de donnees et verifier que tout tient dans la taille reelle du fichier en tant que partie d'une verification de validite du fichier. Lors d'une seconde intercalaire positive, les lecteurs devraient ajouter une seconde supplementaire a la minute locale contenant la seconde juste avant la seconde intercalaire. Si cela se produit quand le decalage UTC n'est pas un multiple de 60 secondes, la seconde intercalaire arrive plus tot que la derniere seconde de la minute locale et les secondes restantes de la minute sont numerotees jusqu'a 60 au lieu du 59 habituel. Le decalage UTC n'est pas affecte. Problemes courants d'interoperabilite Cette section documente les problemes courants de lecture et d'ecriture de fichiers TZif. La plupart d'entre eux concerne la creation de fichiers TZif pour une utilisation par d'anciens lecteurs. Cette section a pour buts d'aider : - les ecrivains TZif a produire des fichiers evitant les pieges dans les lecteurs TZif anciens ou bogues ; - les lecteurs TZif a eviter les pieges lors de la lecture crees par de futurs ecrivains TZif ; - de futurs auteurs de specification a voir quelles sortes de probleme se produisent quand le format de TZif est modifie. Quand de nouvelles versions du format TZif ont ete definies, un but de conception etait qu'un lecteur pouvait utiliser avec succes un fichier TZif meme si le fichier etait d'une version de TZif posterieure au moment de la conception du lecteur. Lorsque la compatibilite n'etait pas totale, une tentative etait faite de limiter les bogues aux horodatages rarement utilises et d'autoriser des contournements partiels simples dans les lecteurs concus pour generer des donnees de version plus recente utiles meme pour les lecteurs de version ancienne. Cette section veut documenter ces problemes de compatibilite et les contournements, ainsi que les autres bogues courants dans les lecteurs. Les problemes d'interoperabilite avec TZif incluent les suivants : - certains lecteurs examinent uniquement les donnees de version 1. Comme contournement partiel, un ecrivain peut produire autant de donnees de version 1 que possible. Cependant, un lecteur devrait ignorer les donnees de version 1 et devrait utiliser une version 2+ meme si les horodatages natifs de lecteur ont seulement 32 bits ; - certains lecteurs concus pour la version 2 pourraient mal gerer les horodatages apres la derniere transition de fichier de version 3 ou superieure, car ils ne peuvent analyser les extensions POSIX.1-2024 a POSIX.1-2017 dans la chaine TZ proleptique. Comme contournement partiel, un ecrivain peut produire plus de transitions que necessaires de facon que seuls les horodatages d'un futur eloigne soient mal geres par les lecteurs de version 2 ; - certains lecteurs pourraient mal gerer les horodatages apres la derniere transition de fichier, car ils necessitent que toutes les abreviations ou decalages par rapport au temps universel dans la chaines TZ proleptique apparaissent aussi quelque part dans les tables de designations de zone horaire et les enregistrements de type heure locale du fichier. Comme contournement, un ecrivain peut produire plus de transitions que necessaires de facon que les autres tables contiennent des duplications des abreviations et decalages de la chaine TZ proleptique. - certains lecteurs concus pour la version 2 ne gerent pas les heures d'ete permanentes avec des transitions apres 24:00 - par exemple, une chaine TZ "EST5EDT,0/0,J365/25" indiquant l'heure d'ete permanente de l'est (-04). Comme contournement un ecrivain peut substituer l'heure standard pour deux zones horaires a l'est, par exemple, "XXX3EDT4,0/0,J365/23" pour une zone horaire avec une heure standard jamais utilisee (XXX, -03) et une heure d'ete negative (EDT, -04) toute l'annee. Sinon, comme contournement partiel, un ecrivain peut substituer l'heure standard pour la zone horaire est suivante - par exemple, "AST4" pour l'heure permanente standard atlantique (-04) ; - certains lecteurs concus pour les versions 2 ou 3 et qui requierent une stricte conformite a la RFC 9636 rejettent les fichiers de version 4 dont la table des secondes intercalaires est tronquee au debut ou a la fin des dates d'expiration ; - certains lecteurs ignorent le bas de page et a la place deduisent les horodatages futurs a partir du type de temps de la derniere transition. Comme contournement partiel, un ecrivain peut produire plus de transitions que necessaires ; - Certains lecteurs basiques ignorent tout sauf le bas de page, et utilisent sa chaine TZ proleptique pour calculer tous les horodatages. Alors que cette approche fonctionne souvent avec les horodatages actuels et futurs, elle pose assurement probleme avec les horodatages passes, et meme avec les horodatages actuels, elle peut echouer pour des reglages comme TZ="Africa/Casablanca". Cela correspond a un fichier TZif contenant des transitions explicites jusqu'a l'annee 2087, suivies d'un bas de page contenant la chaine TZ "<+01>-1", qui ne doit etre utilisee que pour les horodatages apres la derniere transition explicite. - certains lecteurs n'utilisent pas le type 0 de temps pour les horodatages avant la premiere transition, en cela ils inferent un type de temps en utilisant une heuristique ne selectionnant pas toujours un type 0 de temps. Comme contournement partiel, un ecrivain peut produire une premiere transition factice (no-op) a une date rapprochee ; - certains lecteurs gerent mal les horodatages avant la premiere transition ayant un horodatage d'au moins -2**31. Les lecteurs qui gerent seulement les horodatages de 32 bits sont vraisemblablement plus sujets a ce probleme, par exemple, quand ils traitent des transitions 64 bits et que seules quelques-unes sont representables en 32 bits. Comme contournement partiel, un ecrivain peut produire une transition factice d'horodatage -2**31 ; - certains lecteurs gerent mal une transition si son horodatage a la valeur minimale 64 bits signee possible. Les horodatages inferieurs a -2**59 ne sont pas recommandes ; - certains lecteurs gerent mal les chaines TZ proleptiques contenant "<" ou ">". Comme contournement partiel, un ecrivain peut eviter d'utiliser "<" ou ">" pour des abreviations de zone horaire contenant seulement des caracteres alphabetiques ; - beaucoup de lecteurs gerent mal les abreviations de zone horaire contenant des caracteres non ASCII. Ces caracteres ne sont pas recommandes ; - certains lecteurs peuvent mal gerer les abreviations contenant moins de trois caracteres ou plus de six, ou qui contiennent des caracteres ASCII autres que alphanumeriques, "-", et "+". Ces abreviations ne sont pas recommandees ; - certains lecteurs gerent mal les fichiers TZif qui specifient les decalages d'heure d'ete en temps universel qui sont inferieurs aux decalages de temps universel pour les temps standard correspondants. Ces lecteurs ne gerent pas des emplacements tels que l'Irlande qui utilise l'equivalent de la chaine TZ "IST-1GMT0,M10.5.0,M3.5.0/1", observant le temps standard (Irish Standard Time, +01) en ete et l'heure d'ete (GMT, +00) en hiver. Comme contournement partiel, un ecrivain peut produire des donnees pour l'equivalent de la chaine TZ "GMT0IST,M3.5.0/1,M10.5.0", par consequent echangeant le temps standard et l'heure d'ete. Bien que ce contournement identifie mal quelle partie de l'annee utilise l'heure d'ete, il enregistre les decalages de temps universel et les abreviations de zone horaire correctement. - certains lecteurs generent des horodatages ambigus pour les secondes intercalaires positives qui arrivent quand le decalage UTC n'est pas un multiple de 60 secondes. Par exemple, avec le decalage UTC +01:23:45 et avec une seconde intercalaire positive 78796801 (1972-06-30 23:59:60 UTC), certains lecteurs feront correspondre a la fois 78796800 et 78796801 au temps local 01:23:45 le jour suivant au lieu de faire correspondre le dernier a 01:23:46, et ils feront correspondre 78796815 a 01:23:59 au lieu de 01:23:60. Cela n'a pas encore ete un probleme pratique puisqu'aucune autorite civile n'a observe de tels decalages UTC depuis que les secondes intercalaires ont ete introduites en 1972. Certains problemes d'interoperabilite sont des bogues de lecteur qui sont listes ici pour servir principalement d'avertissements aux developpeurs de lecteurs : - certains lecteurs ne gerent pas les horodatages negatifs. Les developpeurs d'applications distribuees devraient s'en souvenir s'ils ont besoin de traiter des donnees d'avant 1970 ; - certains lecteurs gerent mal les horodatages avant la premiere transition ayant un horodatage non negatif. Les lecteurs qui ne gerent pas les horodatages negatifs sont plus sujets a ce probleme ; - certains lecteurs gerent mal les abreviations de zone horaire telles que "-08" qui contiennent "+", "-", ou des chiffres ; - certains lecteurs gerent mal les decalages de temps universel qui sont hors de la plage traditionnelle -12 a +12 heures, et par consequent ne gerent pas des emplacements tels que Kiritimati qui sont en dehors de cette plage. - certains lecteurs gerent mal les decalages de temps universel dans la plage [-3599, -1] secondes a partir du temps universel parce qu'ils font une division entiere du decalage par 3600 pour obtenir 0 et alors ils affichent la partie heure sous forme "+00". - certains lecteurs gerent mal les decalages de temps universel qui ne sont pas un multiple de 1 heure, 15 minutes ou 1 minute. VOIR AUSSI 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. RFC 9636 Internet doi:10.17487/RFC9636 . TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Lucien Gentis Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Base de donnees de zones horaires tzfile(5)