Provided by: manpages-fr_4.21.0-2_all 
NOM
tzfile – Informations de zone horaire
DESCRIPTION
Les fichiers d’informations de zone horaire utilisés par tzset(3) sont classiquement
trouvés sous un répertoire avec un nom tel que /usr/share/zoneinfo. Ces fichiers utilisent
le format décrit dans la RFC 8536 à propos d’Internet. Chaque fichier est une séquence de
huit octets. Dans un fichier, un entier binaire est représenté par une séquence de un ou
plusieurs octets dans l’ordre du réseau (gros boutiste ou octets de poids le plus fort en
premier) avec tous les bits significatifs, un entier binaire signé est représenté en
utilisant deux compléments et un booléen est représenté par un entier binaire d’un octet
qui est soit 0 (faux) ou 1 (vrai). Le format commence par un en-tête de 44 octets
contenant les champs suivants :
* la séquence 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 (à partir de 2017, soit un NUL
ASCII) “2”, ou “3”).
* quinze octets contenant des zéros, réservés pour une utilisation future ;
* six valeurs d’entier composées de quatre octets, dans l’ordre suivant :
tzh_ttisutcnt
le nombre d'indicateurs TU/locaux enregistrés dans le fichier (TU est le temps
universel),
tzh_ttisstdcnt
le nombre d'indicateurs standard/locaux enregistrés dans le fichier,
tzh_leapcnt
le nombre de secondes intercalaires pour lesquelles des données sont enregistrées
dans le fichier,
tzh_timecnt
le nombre d’instants de transition pour lesquels des données sont enregistrées
dans le fichier,
tzh_typecnt
le nombre de types d'heure locale pour lesquels des données sont enregistrées
dans le fichier (ne doit pas être zéro),
tzh_charcnt
le nombre d’octets de chaînes d'abréviation de zone horaire enregistrées dans le
fichier.
L’en-tête ci-dessus est suivi des champs ci-après dont la longueur dépend du contenu de
l’en-tête :
* tzh_timecnt Valeurs sous forme d’entier signé de quatre octets, triées dans l’ordre
ascendant. Ces valeurs sont écrites dans l’ordre d’octets du réseau. Chacune est
utilisée comme instant de transition (tel que renvoyé par time(2)) quand les règles de
calcul de l’heure locale changent ;
* tzh_timecnt Valeurs sous forme d’entier non signé d’un octet. Chacune, sauf la dernière,
indique lequel des différents types d’heure locale décrits dans le fichier est associé
avec la période de temps débutant avec l’instant de transition indexé de manière
identique et continuant jusqu’au prochain instant de transition (non inclus). Le dernier
type de temps est présent uniquement pour des raisons de vérification cohérente avec la
chaine TZ de style POSIX décrite ci-après. Ces valeurs servent d’indices dans le champ
suivant ;
* tzh_typecnt Entrées ttinfo, chacune définie comme suit :
struct ttinfo {
int32_t tt_utoff;
unsigned char tt_isdst;
unsigned char tt_desigidx;
};
Chaque structure est écrite comme valeur sous forme d’entier de quatre octets pour
tt_utoff, dans l’ordre des octets du réseau, suivi par un booléen 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 à ajouter au temps universel, tt_isdst indique si tm_isdst
doit être réglé par localtime(3) et tt_desigidx sert d’indice dans le tableau des octets
d’abréviation de zone horaire qui suivent les entrées ttinfo dans le fichier. La valeur
tt_utoff n’est jamais égale à -2**31 pour permettre au clients 32 bits de l’indiquer
sans erreur d’opérande. Aussi, dans les applications réelles, tt_utoff se situe dans
l’intervalle [-89999, 93599] (c’est-à-dire plus de -25 heures et moins de 26 heures).
Cela permet une prise en charge facile par les implémentations qui gèrent déjà
l’intervalle requis par POSIX [-24:59:59, 25:59:59] ;
* tzh_leapcnt Paires de valeurs composées de quatre octets écrits dans l’ordre des octets
du réseau. La première valeur de chaque paire donne le temps non négatif (tel que
renvoyé par time(2)) auquel les secondes intercalaires sont insérées. La seconde valeur
est un entier signé indiquant le nombre total de secondes intercalaires à insérer durant
la période de temps débutant au temps indiqué. Les paires de valeurs sort ordonnées dans
l’ordre ascendant selon le temps. Chaque transition indique une seconde intercalaire
soit positive soit négative. Les transitions sont toujours séparées par au moins
28 jours moins 1 seconde ;
* tzh_ttisstdcnt Indicateurs standard/locaux, chacun stocké sous forme de booléen d’un
octet. Ils indiquent si les instants de transition associés avec les types de temps
local ont été indiqués comme temps standard ou comme temps local (horloge murale) ;
* tzh_ttisutcnt Indicateurs TU/locaux, chacun stocké sous forme de booléen d’un octet. Ils
indiquent si les instants de transition associés avec les types de temps local ont été
indiqués comme temps universel ou comme temps local. Si un indicateur TU/local est
défini, l’indicateur standard/local correspondant doit aussi être défini.
Les indicateurs standard/local et TU/local ont été conçus pour transformer les instants de
transition de fichier TZif en transitions appropriées pour une autre zone horaire
spécifiée à l’aide d’une chaine TZ de style POSIX n’ayant pas de règles. Par exemple,
quand TZ="EET2EEST" et qu’il n’y a pas de fichier TZif « EET2EEST », l’idée était
d’adapter les instants de transition d’un TZif avec le nom très connu « posixrules » qui
existe uniquement dans ce but et qui est une copie du fichier « Europe/Brussels », un
fichier avec un décalage de temps universel différent. POSIX n’indique pas ce comportement
obsolète de transformation, les règles par défaut dépendent de l’installation et aucune
implémentation n’est connue pour prendre en charge cette fonctionnalité pour les
horodatages après 2037, aussi les utilisateurs désirant par exemple l’heure grecque
doivent plutôt préciser TZ="Europe/Athens" pour une meilleure couverture historique,
revenant à TZ="EET2EEST,M3.5.0/3,M10.5.0/4" si une conformité à POSIX est nécessaire et
que les anciens horodatages n’ont pas besoin d’être gérés de manière précise.
La fonction Localtime(3) utilise normalement la première structure ttinfo dans le fichier
si soit tzh_timecnt est zéro ou si son paramètre horaire est antérieur au premier instant
de transition enregistré dans le fichier.
NOTES
Cette page de manuel documente <tzfile.h> dans l’archive source de la glibc, consulter
timezone/tzfile.h.
Il semble que la zone horaire utilise tzfile en interne, mais la glibc refuse de l’exposer
dans l’espace utilisateur. Cela doit être probablement dû à ce que les fonctions
normalisées sont plus utiles et portables, et réellement documentées dans la glibc. Il
peut seulement exister dans la glibc uniquement pour prendre en charge les données de zone
horaire non entretenues par la glibc (et entretenues par quelqu’autre entité).
Format version 2
Pour les fichiers de zone horaire dans le format 2, l'en-tête et les données ci-dessus
sont suivies d'un second en-tête et de données, identiques en format sauf que huit octets
sont utilisés pour chaque instant de transition ou de secondes intercalaires (le compte de
secondes intercalaires est toujours de quatre octets). Après le deuxième en-tête et les
données, vient une chaîne, du même type que la variable d'environnement POSIX TZ, entourée
de sauts de lignes, utilisée pour gérer les instants après le dernier instant de
transition stocké dans le fichier ou pour tous les instants si le fichier n’a pas de
transition. La chaine TZ de style POSIX est vide (c’est-à-dire rien entre les deux sauts
de ligne) s’il n’existe pas de représentation de style POSIX pour de tels instants. Si non
vide, la chaine TZ de style POSIX doit être d’accord avec le type d’heure locale après le
dernier instant de transition si présent dans les données des huit octets. Par exemple, si
la chaine “WET0WEST,M3.5.0,M10.5.0/3” est indiquée, alors si le dernier instant de
transition est en juillet, le type d’heure locale de la transition doit indiquer une heure
d’été abrégée en “WEST” qui est une heure à l’est du temps universel. Aussi, s’il y a au
moins un instant de transition, le type de temps 0 est associé à la période de temps d’un
passé illimité jusqu’au, mais sans l’inclure, tout premier instant de transition.
Format version 3
Pour les fichiers de zone horaire de format version 3, la chaine TZ de style POSIX peut
utiliser deux extensions mineures au format POSIX de TZ, comme décrites dans newtzset(3).
Premièrement, la partie heure peut être signée et aller de -167 jusqu’à 167 au lieu des
valeurs non signées requises par POSIX allant de 0 jusqu’à 24. Deuxièmement, l’heure d’été
est effective toute l’année si elle commence le premier janvier à 00:00 et se termine le
31 décembre à 24:00 plus la différence entre le temps d’heure d’été et le temps standard.
Considérations d’interopérabilité
Des changements futurs au format peuvent ajouter plus de données.
Les fichiers de format version 1 sont considérés comme étant d’un format patrimonial et ne
devraient plus être créés, puisqu’ils ne prennent pas en charge les instants de transition
après l’année 2038. Les lecteurs qui ne comprennent que la version 1 doivent ignorer toute
donnée allant au-delà de la fin délibérée de blocs de données version 1.
Les écrivains devraient créer un fichier version 3 si les extensions de chaine TZ sont
nécessaires pour modéliser précisément les instants de transition. Sinon, des fichiers de
version 2 devraient être créés.
La séquence de modifications de temps définie par l’en-tête et le bloc de données
version 1 devrait être une sous-séquence contigüe des modifications de temps définis par
l’en-tête et le bloc de données version 2+ et par le pied de page. Ces recommandations
aident les écrivains obsolescents de version 1 à s’accorder avec les écrivains actuels à
partir des horodatages dans la sous-séquence contigüe. Elles permettent aussi aux
écrivains ne gérant pas les écrivains obsolescents d’utiliser un tzh_timecnt de zéro dans
le bloc de données version 1 pour économiser de l’espace.
Les désignations de zone horaire devraient consister à au moins trois (3) et pas plus de
six (6) caractères ASCII de l’ensemble alphanumérique, “-”, et “+”. Cela doit l’être pour
une compatibilité avec les exigences de POSIX pour l’abréviation des zones horaires.
Lors de la lecture d’un fichier de version 2 ou 3, les lecteurs devrait ignorer l’en-tête
et le bloc de données version 1 sauf pour les omettre.
Les lecteurs devraient intégrer le calcul des longueurs totales des en-têtes et des blocs
de données et vérifier que tout tient dans la taille réelle du fichier en tant que partie
d’une vérification de validité du fichier.
Problèmes courants d’interopérabilité
Cette section documente les problèmes courants de lecture et d’écriture de fichiers TZif.
La plupart d’entre eux concerne la création de fichiers TZif pour une utilisation par
d’anciens lecteurs. Les buts de cette section sont :
* d’aider les écrivains TZif à produire des fichiers évitant les pièges dans les lecteurs
TZif anciens ou bogués ;
* d’aider les lecteurs TZif à éviter les pièges lors de la lecture créés par de futurs
écrivains TZif ;
* d’aider de futurs auteurs de spécification à voir quelles sortes de problème se
produisent quand le format de TZif est modifié.
Quand de nouvelles versions du format TZif ont été définies, un but de conception était
qu’un lecteur pouvait utiliser avec succès un fichier TZif même si le fichier était d’une
version de TZif postérieure au moment le la conception du lecteur. Lorsque la
compatibilité n’est pas totale, une tentative était faite de limiter les bogues aux
horodatages rarement utilisés et d’autoriser des contournements partiels simples dans les
lecteurs conçus pour générer des données de nouvelle version utiles même pour les lecteurs
de version ancienne. Cette section veut documenter ces problèmes de compatibilité et les
contournements, ainsi que les autres bogues courants dans les lecteurs.
Les problèmes d’interopérabilité avec TZif incluent les suivants :
* certains lecteurs examinent uniquement les données de version 1. Comme contournement
partiel, un écrivain peut produire autant de données de version 1 que possible.
Cependant, un lecteur devrait ignorer les données de version 1 et devrait utiliser une
version 2+ même si les horodatages natifs de lecteur ont seulement 32 bits ;
* certains lecteurs conçus pour la version 2 pourraient mal gérer les horodatages après la
dernière transition de fichier de version 3, car ils ne peuvent analyser les extensions
de POSIX dans les chaines de style TZ. Comme contournement partiel, un écrivain peut
produire plus de transitions que nécessaires de façon que seuls les horodatages d’un
futur éloigné soient mal gérés par les lecteurs de version 2 ;
* certains lecteurs conçus pour la version 2 ne gèrent pas les heures d’été permanentes,
par exemple, une chaine TZ “EST5EDT,0/0,J365/25” indiquant l’heure d’été permanente de
l’est (-04). Comme contournement partiel, un écrivain peut substituer l’heure standard
pour la zone horaire suivante à l’est, par exemple, “AST4” pour l’heure permanente
standard atlantique (-04) ;
* certains lecteurs ignorent le bas de page et à la place déduisent les horodatages futurs
à partir du type de temps de la dernière transition. Comme contournement partiel, un
écrivain peut produire plus de transitions que nécessaires ;
* certains lecteurs n’utilisent pas le type 0 de temps pour les horodatages avant la
première transition, en cela ils infèrent un type de temps en utilisant une heuristique
ne sélectionnant pas toujours un type 0 de temps. Comme contournement partiel, un
écrivain peut produire une première transition factice (no-op) à une date rapprochée ;
* certains lecteurs gèrent mal les horodatages avant la première transition ayant un
horodatage d’au moins -2**31. Les lecteurs qui gèrent seulement les horodatages de
32 bits sont vraisemblablement plus sujets à ce problème, par exemple, quand ils
traitent des transitions 64 bits et que seules quelques-unes sont représentables en
32 bits. Comme contournement partiel, un écrivain peut produire une transition factice
d’horodatage -2**31 ;
* certains lecteurs gèrent mal une transition si son horodatage a la valeur minimale
64 bits signée possible. Les horodatages inférieurs à -2**59 ne sont pas recommandés ;
* certains lecteurs gèrent mal les chaines TZ de style POSIX contenant “<” ou “>”. Comme
contournement partiel, un écrivain peut éviter d’utiliser “<” ou “>” pour des
abréviations de zone horaire contenant seulement des caractères alphabétiques ;
* beaucoup de lecteurs gèrent mal les abréviations de zone horaire contenant des
caractères non ASCII. Ces caractères ne sont pas recommandés ;
* certains lecteurs peuvent mal gérer les abréviations contenant moins de trois caractères
ou plus de six, ou qui contiennent des caractères ASCII autres que alphanumériques, “-”,
et “+”. Ces abréviations ne sont pas recommandées ;
* certains lecteurs gèrent mal les fichiers TZif qui spécifient les décalages d’heure
d’été en temps universel qui sont inférieurs aux décalages de temps universel pour les
temps standard correspondants. Ces lecteurs ne gèrent pas des emplacements tels que
l’Irlande qui utilise l’équivalent de la chaine TZ POSIX “IST-1GMT0,M10.5.0,M3.5.0/1”,
observant le temps standard (Irish Standard Time, +01) en été et l’heure d’été
(GMT, +00) en hiver. Comme contournement partiel, un écrivain peut produire des données
pour l’équivalent de la chaine TZ POSIX “GMT0IST,M3.5.0/1,M10.5.0”, par conséquent
échangeant le temps standard et l’heure d’été. Bien que ce contournement identifie mal
quelle partie de l’année utilise l’heure d’été, il enregistre les décalages de temps
universel et les abréviations de zone horaire correctement.
Certains problèmes d’interopérabilité sont des bogues de lecteur qui sont listés ici pour
servir principalement d’avertissements aux développeurs de lecteurs :
* certains lecteurs ne gèrent pas les horodatages négatifs. Les développeurs
d’applications distribuées devraient s’en souvenir s’ils ont besoin de traiter des
données d’avant 1970 ;
* certains lecteurs gèrent mal les horodatages avant la première transition ayant un
horodatage non négatif. Les lecteurs qui ne gèrent pas les horodatages négatifs sont
plus sujets à ce problème ;
* certains lecteurs gèrent mal les abréviations de zone horaire telles que “-08” qui
contiennent “+”, “-”, ou des chiffres ;
* certains lecteurs gèrent mal les décalages de temps universel qui sont hors de la plage
traditionnelle -12 à +12 heures, et par conséquent ne gèrent pas des emplacements tels
que Kiritimati qui sont en dehors de cette plage.
* certains lecteurs gèrent mal les décalages de temps universel dans la plage [-3599, -1]
secondes à partir du temps universel parce qu’ils font une division entière du décalage
par 3600 pour obtenir 0 et alors ils affichent la partie heure sous forme “+00”.
* certains lecteurs gèrent mal les décalages 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). fév. 2019.
RFC 8536 Internet ⟨https://www.rfc-editor.org/info/rfc8536⟩ doi:10.17487/RFC8536 ⟨https://
doi.org/10.17487/RFC8536⟩.
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry
Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
Barbier <barbier@debian.org> et David Prévot <david@tilapin.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les
conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
message à ⟨debian-l10n-french@lists.debian.org⟩.