Ubuntu Manpages

tzfile

Informations de zone horaire

The timezone information files used by tzset(3) are typically found under a directory with a name like /usr/share/zoneinfo. These files use the format described in Internet RFC 9636. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), with all bits significant, a signed binary integer is represented using two's complement, and a boolean is represented by a one-byte binary integer that is either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields:

–
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 et (à partir de 2021), soit un NUL ASCII “2”, “3”, ou “4”).
–
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 :
le nombre d'indicateurs TU/locaux enregistrés dans le fichier (TU est le temps universel),
le nombre d'indicateurs standard/locaux enregistrés dans le fichier,
le nombre de secondes intercalaires pour lesquelles des données sont enregistrées dans le fichier,
le nombre d’instants de transition pour lesquels des données sont enregistrées dans le fichier,
le nombre de types d'heure locale pour lesquels des données sont enregistrées dans le fichier (ne doit pas être zéro),
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;
};

Each structure is written as a four-byte signed integer value for tt_utoff, in network byte order, followed by a one-byte boolean for tt_isdst and a one-byte value for tt_desigidx. In each structure, tt_utoff gives the number of seconds to be added to UT, tt_isdst tells whether tm_isdst should be set by localtime(3) and tt_desigidx serves as an index into the array of time zone abbreviation bytes that follow the ttinfo entries in the file; if the designated string is "-00", the ttinfo entry is a placeholder indicating that local time is unspecified. The tt_utoff value is never equal to -2**31, to let 32-bit clients negate it without overflow. Also, in realistic applications tt_utoff is in the range [-89999, 93599] (i.e., more than -25 hours and less than 26 hours); this allows easy support by implementations that already support the POSIX-required range [-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 pairs of four-byte values, written in network byte order; the first value of each pair gives the non-negative time (as returned by time(2)) at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the total number of leap seconds to be applied during the time period starting at the given time. The pairs of values are sorted in strictly ascending order by time. Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table's expiration time. Each leap second is at the end of a UTC calendar month. The first leap second has a non-negative occurrence time, and is a positive leap second if and only if its correction is positive; the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, or -1 for a negative leap second. If the leap second table is empty, the leap-second correction is zero for all timestamps; otherwise, for timestamps before the first occurrence time, the leap-second correction is zero if the first pair's correction is 1 or -1, and is unspecified otherwise (which can happen only in files truncated at the start).
–
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.

Cette page de manuel documente <tzfile.h> dans l’archive source de la glibc, consulter timezone/tzfile.h.

It seems that timezone(3) uses tzfile internally, but glibc refuses to expose it to userspace. This is most likely because the standardised functions are more useful and portable, and actually documented by glibc. It may only be in glibc just to support the non-glibc-maintained timezone data (which is maintained by some other entity).

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 non-empty, 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 “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 “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.

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.

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.

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

This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by older readers. The goals of this section are to help:

–
TZif writers output files that avoid common pitfalls in older or buggy TZif readers,
–
TZif readers avoid common pitfalls when reading files generated by future TZif writers, and
–
any future specification authors see what sort of problems arise when the TZif format is changed.

When new versions of the TZif format have been defined, a design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate newer-version data useful even for older-version readers. This section attempts to document these compatibility issues and workarounds as well as documenting other common bugs in readers.

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 “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, “XXX3EDT4,0/0,J365/23” for a time zone with a never-used standard time (XXX, -03) and negative daylight saving time (EDT, -04) all year. Alternatively, as a partial workaround, a writer can substitute standard time for the next time zone east – e.g., “AST4” pour l’heure permanente standard atlantique (-04) ;
–
Some readers designed for version 2 or 3 and that require strict conformance to RFC 9636 reject version 4 files whose leap second tables are truncated at the start or end in expiration times.
–
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 “<+01>-1”, 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 ;
–
Some readers mishandle timestamps before the first transition that has a timestamp that is not less than -2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 bits. As a partial workaround, a writer can output a dummy transition at timestamp -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 ;
–
Some readers mishandle proleptic TZ strings that contain “<” 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 ;
–
Some readers may mishandle time zone abbreviations that contain fewer than 3 or more than 6 characters or that contain ASCII characters other than alphanumerics, “-”, 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 “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 “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.
–
Some readers generate ambiguous timestamps for positive leap seconds that occur when the UTC offset is not a multiple of 60 seconds. For example, with UTC offset +01:23:45 and a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they will map 78796815 to 01:23:59 instead of to 01:23:60. This has not yet been a practical problem, since no civil authority has observed such UTC offsets since leap seconds were introduced in 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 ;
–
Some readers mishandle timestamps before the first transition that has a non-negative timestamp. Readers that do not support negative timestamps are likely to be more prone to this problem.
–
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.
–
Some readers mishandle UT offsets in the range [-3599, -1] seconds from UT because they integer-divide the offset by 3600 to get 0 and then display the hour part as “+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.

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. Internet RFC 9636 doi:10.17487/RFC9636.

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