tzfile(5)

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 identifiant le fichier comme un fichier d’information de zone horaire ;

    -   un octet identifiant la version du format de fichier et (à partir de 2021), soit un NUL ASCII ou

    -   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 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 proleptic TZ string described below.) These values serve as indices into the next field.

    -   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. Si la chaine désignée est « -00 », l’entrée ttinfo est un paramètre fictif indiquant que l’heure locale n’est pas précisée. 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_charcnt 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 tt_desigidx 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é ;

    -   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 ou le moment où la table de secondes intercalaires expire. La seconde valeur est un entier signé indiquant la correction qui est le nombre total 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) ;

    -   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.

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 proleptic 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 the details of 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.

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.

  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 proleptic TZ, 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 proleptic 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 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 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
For version-3-format timezone files, a TZ string (see newtzset(3)) may use the following POSIX.1-2024 extensions to POSIX.1-2017: First, as in TZ="<-02>2<-01>,M3.5.0/-1,M10.5.0/0", the hours part of its transition times may be signed and range from -167 through 167 instead of being limited to unsigned values from 0 through 24. Second, as in TZ="XXX3EDT4,0/0,J365/23", 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.

  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.

  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.

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.

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.

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).

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 supérieure, les lecteurs devraient 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.

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é.

  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 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.

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 ;

    -   Some readers designed for version 2 might mishandle timestamps after a version 3 or higher file's last transition, because they cannot parse the POSIX.1-2024 extensions to POSIX.1-2017 in the proleptic TZ 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.

    -   certains lecteurs conçus pour la version 2 ne gèrent pas les heures d’été permanentes avec des transitions après 24:00 – par exemple, une chaine TZ 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, 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 – par exemple, pour l’heure permanente standard atlantique (-04) ;

    -   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 ;

    -   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 ;

    -   Some stripped-down readers ignore everything but the footer, and use its proleptic TZ string to calculate all timestamps. Although this approach often works for current and future timestamps, it obviously has problems with past timestamps, and even for current timestamps it can fail for settings like TZ="Africa/Casablanca". This corresponds to a TZif file containing explicit transitions through the year 2087, followed by a footer containing the TZ string which should be used only for timestamps after the last explicit transition.

    -   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 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 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 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 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.

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 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

    -   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://datatracker.ietf.org/doc/html/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.