Provided by: manpages-de_4.21.0-2_all 
BEZEICHNUNG
tzfile - Zeitzonen-Informationen
BESCHREIBUNG
Die von tzset(3) verwandten Zeitzoneninformationsdateien liegen typischerweise unterhalb
eines Verzeichnisses mit einem Namen wie /usr/share/zoneinfo. Diese Dateien verwenden das
im Internet-RFC 8536 beschriebene Format. Jede Datei ist eine Sequenz von 8-Bit-Bytes. In
einer Datei wird eine binäre Ganzzahl durch eine Sequenz von einem oder mehreren Bytes in
Netzwerkreihenfolge (bigendian oder hochgradiges Byte zuerst) dargestellt, wobei alle Bits
signifikant sind; eine vorzeichenbehaftete binäre Ganzzahl wird mittels Zweierkomplement
dargestellt und ein logischer Wert wird durch eine binäre Ganzzahl aus einem Byte, die
entweder 0 (falsch) oder 1 (wahr) ist, dargestellt. Das Format beginnt mit einem
44-Byte-Vorspann, der die folgenden Felder enthält:
* Die magische Vierbyte-ASCII-Sequenz “TZif” identifiziert die Datei als
Zeitzoneninformationsdatei.
* Ein Byte identifiziert die Version des Dateiformats (Stand 2017 entweder ein ASCII NUL
oder “2”, oder “3”).
* Fünfzehn bytes, die Nullen enthalten, sind für zukünftige Nutzung reserviert.
* Sechs Vier-byte-Ganzzahlwerte, in der folgenden Reihenfolge:
tzh_ttisutcnt
Anzahl der in der Datei hinterlegten UT-/Lokal-Kennziffern (UT bezeichnet die
Weltzeit).
tzh_ttisstdcnt
Anzahl der in der Datei gespeicherten Standard-/Wall-Kennziffern
tzh_leapcnt
Anzahl der Schaltsekunden, für die Einträge in der Datei gespeichert sind
tzh_timecnt
Anzahl der Übergangszeiten, für die Einträge in der Datei gespeichert sind
tzh_typecnt
Anzahl der lokalen Zeit-Typen, für die Einträge in der Datei gespeichert sind
(dürfen nicht Null sein)
tzh_charcnt
Anzahl der Bytes für in der Datei gespeicherte Zeitzonen-Abkürzungen
Der vorgenannte Vorspann wird von den folgenden Feldern, deren Länge abhängig von den
Inhalten des Vorspanns ist, gefolgt:
* tzh_timecnt: In absteigender Reihenfolge sortierte vorzeichenbehaftete
Vierbyte-Ganzzahlwerte. Diese Werte werden in Netzwerk-Byte-Reihenfolge geschrieben.
Jeder wird als Übergangszeit (wie von time(2) zurückgeliefert) verwandt, zu der sich die
Regeln zur Berechnung der lokalen Zeit ändern.
* tzh_timecnt: 1-Byte-Ganzzahlwerte. Jeder außer dem letzten teilt mit, welcher der
verschiedenen in der Datei beschriebenen Arten lokaler Zeittypen mit welcher
Zeitperiode, die mit der identisch indizierten Übergangszeit beginnt und bis zur (aber
ausschließlich) der nächsten Übergangszeit fortläuft, zugeordnet ist. (Der letzte
Zeittyp ist nur zur Konsistenzprüfung mit der nachfolgend beschriebenen POSIX-artigen
TZ-Zeichenkette vorhanden.) Diese Werte dienen als Index für das nächste Feld.
* tzh_typecnt: ttinfo-Einträge, jeder wie folgt definiert:
struct ttinfo {
int32_t tt_utoff;
unsigned char tt_isdst;
unsigned char tt_desigidx;
};
Jede Struktur besteht aus einem vorzeichenbehafteten 4-Byte-Ganzzahlwert für tt_utoff,
geschrieben in Netzwerk-Byte-Reihenfolge, gefolgt von dem logischen 1-Byte Wert für
tt_isdst und einem 1-Byte-Wert für tt_desigidx. In jeder Struktur legt tt_utoff die
Anzahl Sekunden fest, die zu UT addiert werden, tt_isdst bestimmt, ob tm_isdst von
localtime(3) gesetzt werden soll und tt_desigidx dient als Index im Feld der
Abkürzungsbytes für Zeitzonen, die den ttinfo-Strukturen in der Datei folgen. Der Wert
tt_utoff ist niemals identisch zu -2**31, damit sich 32-Bit-Clients mit ihm ohne
Überlauf aushandeln können. In realistischen Anwendungen ist tt_utoff im Bereich
[-89999, 93599] (d.h. mehr als -25 Stunden und weniger als 25 Stunden); dies erlaubt
leichte Unterstützung durch Implementierungen, die bereits den durch POSIX verlangten
Bereich [-24:59:59, 25:59:59] unterstützen.
* tzh_leapcnt-Paare von 4-Byte-Werten, geschrieben in Netzwerk-Byte-Reihenfolge. Der erste
Wert jedes Paares bezeichnet den nicht negativen Zeitpunkt (Rückgabewert von time(2)),
zu dem die Schaltsekunden auftreten. Der zweite ist eine vorzeichenbehaftete Ganzzahl,
die die gesamte Anzahl der Schaltsekunden festlegt, die während der Zeitperiode, die zu
dem angegebenen Zeitpunkt beginnt, eingelegt werden sollen. Die Wertepaare sind in
aufsteigender Folge nach der Zeit sortiert. Jeder Übergang ist für eine Schaltsekunde,
entweder positiv oder negativ. Übergänge sind immer durch mindestens 28 Tage minus einer
Sekunde getrennt.
* tzh_ttisstdcnt Standard-/Wall-Kennziffern, jede wird als logischer 1-Byte-Wert
gespeichert. Sie geben an, ob die Übergangszeiten, die den lokalen Zeit-Typen zugeordnet
sind, als Standard-Zeit oder als lokale (»wall clock«) Zeit angegeben sind.
* tzh_ttisutcnt UT-/Lokal-Kennziffern, jede als logischer 1-Byte Wert gespeichert. Sie
besagen, ob die den lokalen Zeit-Typen zugeordneten Übergangszeiten als UT oder als
lokale Zeit angegeben wurden. Falls eine UT/locale-Kennziffer gesetzt ist, muss die
entsprechende Standard/Wall-Kennziffer auch gesetzt sein.
Die Standard/Wall- und UT/Local-Kennziffern wurden zur Umwandlung von Übergangszeiten
einer TZif-Datei in geeignete Übergänge für andere Zeitzonen, die mittels einer
POSIX-artigen TZ-Zeichenkette ohne Regeln festgelegt wurde, entwickelt. Ist beispielsweise
TZ="EET2EEST" und es gibt keine TZif-Datei "EET2EEST", dann besteht die Idee darin, die
Regeln aus einer TZif-Datei mit dem gut bekannten Namen »posixrules« anzupassen, die nur
für diesen Zweck existiert und eine Kopie der Datei »Europe/Brussels«, einer Datei mit
einem anderen UT-Versatz, ist. POSIX spezifiziert dieses veraltete Übergangsverhalten
nicht, die Standardregeln hängen von der Installation ab und es gibt keine bekannte
Implementierung, die diese Funktionalität für Zeitstempel nach 2037 implementiert. Um eine
bessere historische Abdeckung zu erreichen, wird auf TZ="EET2EEST,M3.5.0/3,M10.5.0/4"
zurückgefallen, falls POSIX-Konformität benötigt wird und ältere Zeitstempel könnten nicht
korrekt gehandhabt werden.
Die Funktion localtime(3) verwendet normalerweise den ersten ttinfo-Eintrag in der Datei,
wenn entweder tzh_timecnt Null ist oder das Zeit-Argument kleiner ist als der erste in der
Datei abgelegte Übergangszeitpunkt.
ANMERKUNGEN
Diese Handbuchseite beschreibt <tzfile.h> aus dem Glibc-Quelltext (siehe
timezone/tzfile.h).
Es scheint, dass timezone tzfile intern verwendet, aber Glibc das nicht in der
Anwendungsebene verfügbar macht. Der Grund ist höchstwahrscheinlich, dass die
standardisierten Funktionen sinnvoller, besser portierbar und tatsächlich von Glibc
dokumentiert sind. Vermutlich ist es nur in Glibc enthalten, um die nicht von Glibc
(sondern einer anderen Organisation) gepflegten Zeitzonendaten zu unterstützen.
Version-2-Format
Für Zeitzonen-Dateien im Version-2-Format folgen dem oben Beschriebenen (Vorspann und
Daten) ein zweiter Vorspann und Daten in einem ähnlichen Format. Der Unterschied besteht
darin, dass die Übergangszeiten und Schaltsekundenzeiten jeweils mit jeweils acht Byte
kodiert werden (Schaltsekundenzahlen bleiben vier Bytes). Nach dem zweiten Vorspann und
den Daten folgt eine durch Zeilenumbrüche eingeschlossene Zeichenkette im Stil von
POSIX-Zeitzonen-Umgebungsvariablen. Sie ist für die Behandlung der Momente nach der
letzten in der Datei gespeicherten Übergangszeit oder für alle Momente, falls die Datei
keine Übergänge enthält, gedacht. Die POSIX-artige TZ-Zeichenkette ist leer (d.h. nichts
zwischen den Zeilenumbrüchen), falls es keine POSIX-Darstellung für solche Momente gibt.
Falls nicht leer, muss die POSIX-artige Zeichenkette mit dem lokalen Zeittyp nach der
letzten Übergangszeit, falls diese in den Acht-Byte-Daten vorhanden ist, übereinstimmen.
Falls die letzte Übergangszeit bei der beispielhaften Zeichenkette
“WET0WEST,M3.5.0,M10.5.0/3” im Juli gewesen ist, dann muss der lokale Übergangszeittyp die
Sommerzeit festlegen, die mit “WEST” d.h. eine Stunde östlich von UT, festgelegt wird.
Falls es auch mindestens einen Übergang gibt, wird der Zeittyp 0 der Zeitperiode von der
unendlichen Vergangenheit bis zu, aber nicht einschließlich der ersten Übergangszeit
zugeordnet.
Version-3-Format
Für Zeitzonendateien im Version-3-Format darf die POSIX-TZ-artige Zeichenkette zwei
kleinere Erweiterungen gegenüber dem POSIX-TZ-Format verwenden, wie diese in newtzset(3)
beschrieben sind. Zuerst darf der Stundenanteil seiner Übergangszeiten vorzeichenbehaftet
und im Bereich von -167 bis 167 sein, statt wie von POSIX verlangt vorzeichenlos im
Bereich 0 bis 24. Zweitens ist die Sommerzeit das ganze Jahr über effektiv, falls sie am
1. Januar um 00:00 anfängt und am 31. Dezember um 24:00 endet, plus dem Unterschied
zwischen der Sommerzeit und der Standardzeit.
Betrachtungen zur Interoperabilität
In zukünftigen Änderungen des Formats können weitere Daten angehängt werden.
Version-1-Dateien werden als veraltetes Format betrachtet und sollten vermieden werden, da
sie keine Übergangszeiten nach dem Jahr 2038 unterstützen. Leseprogramme, die nur Version
1 verstehen, müssen sämtliche Daten, die hinter dem berechneten Ende des
Version-1-Datenblocks liegen, ignorieren.
Schreibprogramme sollten eine Version-3-Datei erstellen, falls die
TZ-Zeichenkettenerweiterung notwendig ist, um genaue Übergangszeiten zu modellieren.
Andernfalls sollten Version-2-Dateien erstellt werden.
Die Sequenz der durch den Version-1-Vorspann und -Datenblock definierten Zeitänderungen
sollten eine aufeinanderfolgende Teilfolge von Zeitänderungen sein, die durch Version
2+-Vorspann und -Datenblock und dem Nachspann definiert werden. Diese Richtschnur hilft
veralteten Version-1-Leseprogrammen, mit den aktuellen Leseprogrammen über Zeitstempel
innerhalb der aufeinanderfolgenden Teilfolge übereinzustimmen. Es lässt Schreibprogrammen,
die veraltete Leseprogramme nicht unterstützen, einen tzh_timecnt von Null in dem
Version-1-Datenblock verwenden, um Platz zu sparen.
Zeitzonenbezeichnungen sollten aus mindestens drei (3) und nicht mehr als sechs (6)
alphanumerischen ASCII-Zeichen bestehen “-”, und “+”. Dies ist zur Kompatibilität zu
POSIX-Anforderungen für Zeitzonenabkürzungen.
Beim Lesen einer Version 2- oder -3-Datei sollten Leseprogramme den Version-1-Vorspann und
-Datenblock ignorieren und ihn lediglich überspringen.
Leseprogramme sollten als Teil der Gültigkeitsprüfung für die Datei die Gesamtlänge der
Vorspänne und Datenblöcke berechnen und prüfen, dass sie alle in die tatsächliche
Dateigröße hineinpassen.
Häufige Interoperabilitätsprobleme
Dieser Abschnitt dokumentiert häufige Probleme beim Lesen oder Schreiben von TZif-Dateien.
Die meisten Probleme bestehen beim Erstellen von TZif-Dateien für den Einsatz mit älteren
Leseprogrammen. Die Ziele dieses Abschnittes sind:
* TZif-Schreibprogrammen bei der Ausgabe von Dateien zu helfen, um häufige Fallstricke in
älteren oder defekten TZif-Leseprogrammen zu vermeiden,
* TZif-Leseprogrammen dabei zu helfen, häufige Fallstricke beim Lesen von Dateien zu
vermeiden, die durch zukünfigte TZif-Schreibprogramme erstellt wurden und
* allen zukünftigen Autoren der Spezifikation dabei zu helfen, zu sehen, welche Arten von
Problemen auftauchen, wenn das TZif-Format geändert wird.
Wenn neue Versionen des TZif-Formats definiert wurden, war ein Design-Ziel, dass das
Leseprogramm eine TZif-Datei erfolgreich verwenden kann, selbst wenn die Datei für eine
neuere TZif-Version ist, als für die das Leseprogramm entwickelt wurde. Wenn eine
komplette Kompatibilität nicht erreicht wurde, wurde versucht, die Störungen auf selten
benutzte Zeitstempel zu begrenzen und einfache teilweise Umgehungen in Schreibprogrammen,
die für die Daten der neuen Version entwickelt wurden, selbst für Leseprogramme älterer
Versionen zu erlauben.
Interoperabilitätsprobleme mit TZif sind beispielsweise:
* Einige Leseprogramme untersuchen nur Daten der Version 1. Als eine teilweise Umgehung
kann ein Schreibprogramm so viel Daten in Version 1 wie möglich ausgeben. Allerdings
soll ein Leseprogramm Daten der Version 1 ignorieren und Daten der Version 2+ verwenden,
selbst wenn die nativen Zeitstempel des Leseprogramms nur 32 Bit haben.
* Einige für Version 2 entwickelte Leseprogramme könnten Zeitstempel nach dem letzten
Übergang der Version 3-Datei handhaben, da sie keine Erweiterungen gegenüber POSIX in
der TZ-artigen Zeichenkette auswerten können. Als teilweise Umgehung kann ein
Schreibprogramm mehr Übergänge als notwendig ausgeben, so dass nur weit in der Zukunft
liegende Zeitstempel von Leseprogrammen der Version 2 falsch gehandhabt werden.
* Einige Leseprogramme, die für Version 2 entwickelt wurden, unterstützen keine dauerhafte
Sommerzeit, z.B. eine TZ-Zeichenkette “EST5EDT,0/0,J365/25” , die dauerhafte Eastern
Daylight Time (-04) angibt. Als teilweise Umgehung kann ein Schreibprogramm als Ersatz
die Normalzeit für die nächste östliche Zeitzone verwenden, z.B. “AST4” für dauerhafte
Atlantic Standard Time (-04).
* Einige Leseprogramme ignorieren den Nachspann und sagen stattdessen zukünftige
Zeitstempel vom Zeittyp des letzten Übergangs her vorher. Als teilweise Umgehung kann
ein Schreibprogramm mehr Übergänge als notwendig ausgeben.
* Einige Leseprgoramme verwenden nicht den Zeittyp 0 für Zeitstempel vor dem ersten
Übergang, sondern erschließen sich den Zeittyp mittels einer Heuristik, die nicht immer
den Zeittyp 0 auswählt. Als teilweise Umgehung kann ein Schreibprogramm einen unechten
(no-op) ersten Übergang zu einem früheren Zeitpunkt ausgeben.
* Einige Leseprogramme handhaben Zeitstempel vor dem ersten Übergang, die einen
Zeitstempel mit nicht weniger als -2**31 haben, falsch. Leseprogramme, die nur
32-Bit-Zeitstempel unterstützen, sind wahrscheinlich anfälliger für dieses Problem,
beispielsweise wenn sie 64-Bit-Übergänge verarbeiten, die nur teilweise in 32 Bit
darstellbar sind. Als eine mögliche Umgehung kann ein Schreibprogramm unechte Übergänge
beim Zeitstempel -2**31 ausgeben.
* Einige Leseprogramme handhaben Übergänge falsch, falls ihre Zeitstempel den minimal
möglichen 64-Bit-Wert haben. Zeitstempel kleiner -2**59 werden nicht empfohlen.
* Einige Leseprogramme handhaben POSIX-artige TZ-Zeichenketten falsch, die Folgendes
enthalten: “<” oder “>”. Als teilweise Umgehung kann ein Schreibprogramm vermeiden, “<”
oder “>” für Zeitzonenabkürzungen zu verwenden, die nur alphabetische Zeichen enthalten.
* Viele Leseprogramme handbaben Zeitzonenabkürzungen, die andere als ASCII-Zeichen
enthalten, falsch. Diese Zeichen werden nicht empfohlen.
* Einige Leseprogramme könnten Zeitzonenabkürzungen, die weniger als 3 und mehr als 6
Zeichen oder nichtalphanumerische ASCII-Zeichen enthalten, falsch handhaben. “-”, und
“+”. Diese Abkürzungen werden nicht empfohlen.
* Einige Leseprogramme handhaben TZif-Dateien falsch, die einen Sommerzeit-UT-Versatz
festlegen, der kleiner als der UT-Versatz für die entsprechende Standardzeit ist. Diese
Leseprogramme unterstützen Orte wie Irland nicht, die das Äquivalent zu der
POSIX-TZ-Zeichenkette “IST-1GMT0,M10.5.0,M3.5.0/1”, verwenden und Standardzeit (IST,+01)
im Sommer und Sommerzeit (GMT,+00) im Winter verwenden. Als teilweise Umgehung kann ein
Schreibprogramm Daten für das Äquivalent der POSIX-TZ-Zeichenkette
“GMT0IST,M3.5.0/1,M10.5.0”, ausgeben und damit Standard- und Sommerzeit vertauschen.
Obwohl diese Umgehung falsch den Teil des Jahres kennzeichnet, der Sommerzeit verwendet,
zeichnet sie UT-Versätze und Zeitzonenabkürzungen korrekt auf.
Einige Interoperabilitätsprobleme sind Fehler von Leseprogrammen, die hier hauptsächlich
als Warnung an Entwickler von Leseprogrammen aufgeführt sind.
* Einige Leseprogramme unterstützen keine negativen Zeitstempel. Entwickler von verteilten
Anwendungen sollten dies im Hinterkopf behalten, falls sie mit Daten vor 1970 umgehen
müssen.
* Einige Leseprogramme handhaben Zeitstempel vor dem ersten Übergang, der einen
nichtnegativen Zeitstempel hat, falsch. Leseprogramme, die keine negativen Zeitstempel
unterstützen, sind wahrscheinlich anfälliger für dieses Problem.
* Einige Leseprogramm handhaben Zeitzonenabkürzungen wie “-08” die “+”, “-”, oder Ziffern
enthalten.
* Einige Leseprogramme handhaben UT-Versätze, die außerhalb des traditionellen Bereichs
von -12 bis 12 Stunden sind, nicht korrekt, und unterstützen damit Orte wie Kiritimati,
die außerhalb dieses Bereichs liegen, nicht.
* Einige Leseprogramme handhaben UT-Versätze im Bereich [-3599, -1] Sekunden von UT nicht
korrekt, da sie eine Ganzzahldivision des Versatzes durch 3600 durchführen, um 0 zu
erhalten, und dann den Stundenanteil wie folgt anzeigen: “+00”.
* Einige Leseprogramme handhaben UT-Versätze nicht korrekt, die nicht ein Vielfaches einer
Stunde oder von 15 Minuten oder einer Minute sind.
SIEHE AUCH
time(2), localtime(3), tzset(3), tzselect(8), zdump(8), zic(8).
Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). 2019 Feb.
Internet RFC 8536 ⟨https://www.rfc-editor.org/info/rfc8536⟩ doi:10.17487/RFC8536 ⟨https://
doi.org/10.17487/RFC8536⟩.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer
<Martin.E.Schauer@gmx.de>, Helge Kreutzmann <debian@helgefjell.de> und Mario Blättermann
<mario.blaettermann@gmail.com> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.