.\" -*- coding: UTF-8 -*-
.\" This file is in the public domain, so clarified as of
.\" 1996-06-05 by Arthur David Olson.
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH tzfile 5 "" "Base de données de zones horaires"
.SH NOM
tzfile – Informations de zone horaire
.SH DESCRIPTION
.ie '\(lq'' .ds lq \&"\"
.el .ds lq \(lq\"
.ie '\(rq'' .ds rq \&"\"
.el .ds rq \(rq\"
.de q
\\$3\*(lq\\$1\*(rq\\$2
..
.ie \n(.g .ds - \f(CR-\fP
.el .ds - \-
Les fichiers d’informations de zone horaire utilisés par \fBtzset\fP(3) sont
classiquement trouvés sous un répertoire avec un nom tel que
\fI/usr/share/zoneinfo\fP. 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 :
.RS "\w' 'u"
.IP \- "\w'\(bu 'u"
la séquence magique ASCII de quatre octets
.q TZif
identifiant le fichier comme un fichier d’information de zone horaire ;
.IP \-
un octet identifiant la version du format de fichier et (à partir de 2021),
soit un NUL ASCII
.q 2 ,
.q 3 ,
ou
.q 4 ).
.IP \-
quinze octets contenant des zéros, réservés pour une utilisation future ;
.IP \-
six valeurs d’entier composées de quatre octets, dans l’ordre suivant :
.RS "\w' \(bu 'u"
.TP "\w' 'u"
\fBtzh_ttisutcnt\fP
le nombre d'indicateurs TU/locaux enregistrés dans le fichier (TU est le
temps universel),
.TP
\fBtzh_ttisstdcnt\fP
le nombre d'indicateurs standard/locaux enregistrés dans le fichier,
.TP
\fBtzh_leapcnt\fP
le nombre de secondes intercalaires pour lesquelles des données sont
enregistrées dans le fichier,
.TP
\fBtzh_timecnt\fP
le nombre d’instants de transition pour lesquels des données sont
enregistrées dans le fichier,
.TP
\fBtzh_typecnt\fP
le nombre de types d'heure locale pour lesquels des données sont
enregistrées dans le fichier (ne doit pas être zéro),
.TP
\fBtzh_charcnt\fP
le nombre d’octets de chaînes d'abréviation de zone horaire enregistrées
dans le fichier.
.RE
.PP
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 :
.RS "\w' 'u"
.IP \- "\w'\(bu 'u"
\fBtzh_timecnt\fP 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 \fBtime\fP(2)) quand les règles de calcul de l’heure locale changent ;
.IP \-
\fBtzh_timecnt\fP one\-byte unsigned integer values; each one but the last tells
which of the different types of local time types described in the file is
associated with the time period starting with the same\-indexed transition
time and continuing up to but not including the next transition time. (The
last time type is present only for consistency checking with the
POSIX.1\-2017\-style TZ string described below.) These values serve as
indices into the next field.
.IP \-
\fBtzh_typecnt\fP Entrées \fBttinfo\fP, chacune définie comme suit :
.in +2
.sp
.nf
.ta \w'\0\0\0\0'u +\w'unsigned char\0'u
struct ttinfo {
int32_t tt_utoff;
unsigned char tt_isdst;
unsigned char tt_desigidx;
};
.in
.fi
.sp
Chaque structure est écrite comme valeur sous forme d’entier de quatre
octets pour \fBtt_utoff\fP, dans l’ordre des octets du réseau, suivi par un
booléen d’un octet pour \fBtt_isdst\fP et une valeur d’un octet pour
\fBtt_desigidx\fP. Dans chaque structure, \fBtt_utoff\fP donne le nombre de
secondes à ajouter au temps universel, \fBtt_isdst\fP indique si \fBtm_isdst\fP
doit être réglé par \fBlocaltime\fP(3) et \fBtt_desigidx\fP sert d’indice dans le
tableau des octets d’abréviation de zone horaire qui suivent les entrées
\fBttinfo\fP dans le fichier. Si la chaine désignée est « \*\-00 », l’entrée
\fBttinfo\fP est un paramètre fictif indiquant que l’heure locale n’est pas
précisée. La valeur \fBtt_utoff\fP 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, \fBtt_utoff\fP 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] ;
.RS "\w' 'u"
.IP \- "\w'\(bu 'u"
\fBtzh_charcnt\fP Octets représentant des désignations de zone horaire, qui
sont des chaines terminées par un octet NULL, chacune indicées par les
valeurs \fBtt_desigidx\fP mentionnées ci\-dessus. Les chaines d’octets peuvent
se chevaucher si une est un suffixe de l’autre. L’encodage de ces chaines
n’est pas précisé ;
.IP \-
\fBtzh_leapcnt\fP 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 \fBtime\fP(2)) auquel les secondes
intercalaires sont insérées ou le moment où la table de secondes
intercalaires expire. La seconde valeur est un entier signé indiquant la
correction qui est le nombre \fItotal\fP de secondes intercalaires a insérer
durant la période de temps débutant au temps indiqué. Les paires de valeurs
sont ordonnées strictement selon le temps. Chaque paire indique une seconde
intercalaire soit positive soit négative, excepté que si la dernière paire a
la même correction que la précédente, la dernière paire indique l’instant
d’expiration de la table de secondes intercalaires. Chaque seconde
intercalaire se produit à la fin d’un mois calendaire du temps universel
coordonné (UTC). La première seconde intercalaire a un temps d’occurrence
non négatif et est une seconde intercalaire positive que si, et uniquement
si, sa correction est positive. La correction pour chaque seconde
intercalaire après la première diffère de la seconde intercalaire précédente
de 1 pour une seconde intercalaire positive ou de \-1 pour une seconde
intercalaire négative. Si la table de secondes intercalaires est vide, la
correction de seconde intercalaire est zéro pour tous les
horodatages. Sinon, pour les horodatages avant le temps de la première
occurrence, la correction de seconde intercalaire est zéro si la première
correction de paire est 1 ou \-1, et est autrement non précisée (ce qui peut
se produire seulement dans des fichiers tronqués au démarrage) ;
.IP \-
\fBtzh_ttisstdcnt\fP 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) ;
.IP \-
\fBtzh_ttisutcnt\fP 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.
.RE
.PP
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 POSIX.1\-2017\-style 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 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.
.PP
La fonction \fBLocaltime\fP(3) utilise normalement la première structure
\fIttinfo\fP dans le fichier si soit \fItzh_timecnt\fP est zéro ou si son
paramètre horaire est antérieur au premier instant de transition enregistré
dans le fichier.
.SS "Format version 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 POSIX.1\-2017 TZ
environment variable, 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
POSIX.1\-2017\-style representation for such instants. If nonempty, 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
.q WET0WEST,M3.5.0/1,M10.5.0
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
.q 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.
.SS "Format version 3"
For version\-3\-format timezone files, the TZ string may use two minor
extensions to the POSIX.1\-2017 TZ format, as described in \fBnewtzset\fP(3).
First, the hours part of its transition times may be signed and range from
\-167 through 167 instead of the POSIX\-required unsigned values from 0
through 24. Second, 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.
.SS "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
représenter la troncature du fichier TZif au démarrage. Aussi, si deux ou
plus transitions de seconde intercalaire sont présentes et que la correction
de la dernière entrée égale celle qui la précède, la dernière entrée indique
l’expiration de la table de secondes intercalaires au lieu d’une seconde
intercalaire. Les horodatages après cette expiration ne sont pas fiables par
le fait que de prochaines publications ajouteront probablement des entrées
de seconde intercalaire après l’expiration, et que les secondes
intercalaires ajoutées changeront la façon dont les horodatages
post\-expiration seront traités.
.SS "Considérations d’interopérabilité"
Des changements futurs au format peuvent ajouter plus de données.
.PP
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.
.PP
Autrement que pour la version 1, les écrivains devraient générer le numéro
de version le plus petit nécessaire pour les données d’un fichier. Par
exemple, un écrivain devrait créer un fichier de version 4 seulement si sa
table de secondes intercalaires expire ou est tronquée au démarrage. De la
même façon, un écrivain ne créant pas un fichier de version 4 devrait créer
un fichier de version 3 seulement si les extensions de chaine TZ sont
nécessaires pour modeler précisément les instants de transition.
.PP
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 \fBtzh_timecnt\fP de zéro
dans le bloc de données version 1 pour économiser de l’espace.
.PP
Quand un fichier TZif contient une date d’expiration de table de secondes
intercalaires, les écrivains 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).
.PP
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,
.q \*- ,
et
.q + .
Cela doit l’être pour une compatibilité avec les exigences de POSIX pour
l’abréviation des zones horaires.
.PP
Lors de la lecture d’un fichier de version 2 ou supérieure, les lecteurs
devraient ignorer l’en\-tête et le bloc de données version 1 sauf pour les
omettre.
.PP
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.
.PP
Lors d’une seconde intercalaire positive, les lecteurs devraient ajouter une
seconde supplémentaire à la minute locale contenant la seconde juste avant
la seconde intercalaire. Si cela se produit quand le décalage UTC n’est pas
un multiple de 60 secondes, la seconde intercalaire arrive plus tôt que la
dernière seconde de la minute locale et les secondes restantes de la minute
sont numérotées jusqu’à 60 au lieu du 59 habituel. Le décalage UTC n’est pas
affecté.
.SS "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 :
.RS "\w' 'u"
.IP \- "\w'\(bu 'u"
d’aider les écrivains TZif à produire des fichiers évitant les pièges dans
les lecteurs TZif anciens ou bogués ;
.IP \-
d’aider les lecteurs TZif à éviter les pièges lors de la lecture créés par
de futurs écrivains TZif ;
.IP \-
d’aider de futurs auteurs de spécification à voir quelles sortes de problème
se produisent quand le format de TZif est modifié.
.RE
.PP
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 de la
conception du lecteur. Lorsque la compatibilité n’était 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.
.PP
Les problèmes d’interopérabilité avec TZif incluent les suivants :
.RS "\w' 'u"
.IP \- "\w'\(bu 'u"
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 ;
.IP \-
Some readers designed for version 2 might mishandle timestamps after a
version 3 or higher file's last transition, because they cannot parse
extensions to POSIX.1\-2017 in the TZ\-like string. As a partial workaround,
a writer can output more transitions than necessary, so that only far\-future
timestamps are mishandled by version 2 readers.
.IP \-
certains lecteurs conçus pour la version 2 ne gèrent pas les heures d’été
permanentes avec des transitions après 24:00 \(en\ par exemple, une
chaine TZ
.q EST5EDT,0/0,J365/25
indiquant l’heure d’été permanente de l’est (\-04). Comme contournement un
écrivain peut substituer l’heure standard pour deux zones horaires à l’est,
par exemple,
.q XXX3EDT4,0/0,J365/23
pour une zone horaire avec une heure standard jamais utilisée (XXX, \-03) et
une heure d’été négative (EDT, \-04) toute l’année. Sinon, comme
contournement partiel, un écrivain peut substituer l’heure standard pour la
zone horaire est suivante \(en\ par exemple,
.q AST4
pour l’heure permanente standard atlantique (\-04) ;
.IP \-
certains lecteurs conçus pour les versions 2 ou 3 et qui requièrent une
stricte conformité à la RFC 8536 rejettent les fichiers de version 4 dont la
table des secondes intercalaires est tronquée au début ou à la fin des dates
d’expiration ;
.IP \-
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 ;
.IP \-
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 ;
.IP \-
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 ;
.IP \-
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 ;
.IP \-
Some readers mishandle TZ strings that contain
.q <
ou
.q > .
Comme contournement partiel, un écrivain peut éviter d’utiliser
.q <
ou
.q >
pour des abréviations de zone horaire contenant seulement des caractères
alphabétiques ;
.IP \-
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 ;
.IP \-
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,
.q \*- ,
et
.q + .
Ces abréviations ne sont pas recommandées ;
.IP \-
Some readers mishandle TZif files that specify daylight\-saving time UT
offsets that are less than the UT offsets for the corresponding standard
time. These readers do not support locations like Ireland, which uses the
equivalent of the TZ string
.q IST\*-1GMT0,M10.5.0,M3.5.0/1 ,
observing standard time (IST, +01) in summer and daylight saving time (GMT,
+00) in winter. As a partial workaround, a writer can output data for the
equivalent of the TZ string
.q 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.
.IP \-
certains lecteurs génèrent des horodatages ambigus pour les secondes
intercalaires positives qui arrivent quand le décalage UTC n’est pas un
multiple de 60 secondes. Par exemple, dans une zone horaire avec le décalage
UTC +01:23:45 et avec une seconde intercalaire positive 78796801 (1972\-06\-30
23:59:60 UTC), certains lecteurs feront correspondre à la fois 78796800 et
78796801 au temps local 01:23:45 le jour suivant au lieu de faire
correspondre le dernier à 01:23:46, et ils feront correspondre 78796815 à
01:23:59 au lieu de 01:23:60. Cela n’a pas encore été un problème pratique
puisqu’aucune autorité civile n’a observé de tels décalages UTC depuis que
les secondes intercalaires ont été introduites en 1972.
.RE
.PP
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 :
.RS "\w' 'u"
.IP \- "\w'\(bu 'u"
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 ;
.IP \-
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 ;
.IP \-
certains lecteurs gèrent mal les abréviations de zone horaire telles que
.q \*-08
qui contiennent
.q + ,
.q \*- ,
ou des chiffres ;
.IP \-
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.
.IP \-
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
.q +00 .
.IP \-
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.
.RE
.SH "VOIR AUSSI"
\fBtime\fP(2), \fBlocaltime\fP(3), \fBtzset\fP(3), \fBtzselect\fP(8), \fBzdump\fP(8),
\fBzic\fP(8).
.PP
Olson A, Eggert P, Murchison K. The Time Zone Information Format
(TZif). fév 2019
.UR https://\:datatracker.ietf.org/\:doc/\:html/\:rfc8536
RFC 8536 Internet
.UE
.UR https://\:doi.org/\:10.17487/\:RFC8536
doi:10.17487/RFC8536
.UE .
.PP
.SH TRADUCTION
La traduction française de cette page de manuel a été créée par
Christophe Blaess ,
Stéphan Rafin ,
Thierry Vignaud ,
François Micaux,
Alain Portal ,
Jean-Philippe Guérard ,
Jean-Luc Coulon (f5ibh) ,
Julien Cristau ,
Thomas Huriaux ,
Nicolas François ,
Florentin Duneau ,
Simon Paillard ,
Denis Barbier
et
David Prévot
.
.PP
Cette traduction est une documentation libre ; veuillez vous reporter à la
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License version 3
.UE
concernant les conditions de copie et
de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
.PP
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
.MT debian-l10n-french@lists.debian.org
.ME .