tzfile(5) File Formats Manual tzfile(5) 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 binare Ganzzahl durch eine Sequenz von einem oder mehreren Bytes in Netzwerkreihenfolge (bigendian oder hochgradiges Byte zuerst) dargestellt, wobei alle Bits signifikant sind; eine vorzeichenbehaftete binare Ganzzahl wird mittels Zweierkomplement dargestellt und ein logischer Wert wird durch eine binare 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 enthalt: o Die magische Vierbyte-ASCII-Sequenz "TZif" identifiziert die Datei als Zeitzoneninformationsdatei. o Ein Byte identifiziert die Version des Dateiformats (Stand 2021 entweder ein ASCII NUL "2", "3", oder "4"). o Funfzehn bytes, die Nullen enthalten, sind fur zukunftige Nutzung reserviert. o 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, fur die Eintrage in der Datei gespeichert sind tzh_timecnt Anzahl der Ubergangszeiten, fur die Eintrage in der Datei gespeichert sind tzh_typecnt Anzahl der lokalen Zeit-Typen, fur die Eintrage in der Datei gespeichert sind (durfen nicht Null sein) tzh_charcnt Anzahl der Bytes fur in der Datei gespeicherte Zeitzonen-Abkurzungen Der vorgenannte Vorspann wird von den folgenden Feldern, deren Lange abhangig von den Inhalten des Vorspanns ist, gefolgt: o tzh_timecnt: In absteigender Reihenfolge sortierte vorzeichenbehaftete Vierbyte-Ganzzahlwerte. Diese Werte werden in Netzwerk-Byte-Reihenfolge geschrieben. Jeder wird als Ubergangszeit (wie von time(2) zuruckgeliefert) verwandt, zu der sich die Regeln zur Berechnung der lokalen Zeit andern. o tzh_timecnt: 1-Byte-Ganzzahlwerte. Jeder ausser dem letzten teilt mit, welcher der verschiedenen in der Datei beschriebenen Arten lokaler Zeittypen mit welcher Zeitperiode, die mit der identisch indizierten Ubergangszeit beginnt und bis zur (aber ausschliesslich) der nachsten Ubergangszeit fortlauft, zugeordnet ist. (Der letzte Zeittyp ist nur zur Konsistenzprufung mit der nachfolgend beschriebenen POSIX.1-2017-artigen TZ-Zeichenkette vorhanden.) Diese Werte dienen als Index fur das nachste Feld. o tzh_typecnt: ttinfo-Eintrage, 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 fur tt_utoff, geschrieben in Netzwerk-Byte-Reihenfolge, gefolgt von dem logischen 1-Byte-Wert fur tt_isdst und einem 1-Byte-Wert fur 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 Abkurzungsbytes fur Zeitzonen, die den ttinfo-Eintragen in der Datei folgen; falls die vorgesehene Zeichenkette >>-00<< ist, dann ist der ttinfo-Eintrag ein Platzhalter, der anzeigt, dass die lokale Zeit nicht spezifiziert wurde. Der Wert tt_utoff ist niemals identisch zu -2**31, damit sich 32-Bit-Clients mit ihm ohne Uberlauf aushandeln konnen. In realistischen Anwendungen ist tt_utoff im Bereich [-89999, 93599] (d.h. mehr als -25 Stunden und weniger als 25 Stunden); dies erlaubt leichte Unterstutzung durch Implementierungen, die bereits den durch POSIX verlangten Bereich [-24:59:59, 25:59:59] unterstutzen. o tzh_charcnt bytes, die das Zeitzonen-Ziel (Byte-Zeichenketten, die mit NULL enden) darstellen, jeweils durch die oben erwahnten tt_desigidx-Werte indiziert. Die Byte-Zeichenketten konnen sich uberlappen, falls eine an eine andere angehangt ist. Die Kodierung dieser Zeichenketten ist nicht spezifiziert. o tzh_leapcnt Paare von Vier-Byte-Werten, geschrieben in der Netzwerk-Byte-Reihenfolge; der erste Wert jedes Paars gibt die nicht negative Zeit (wie von time(2) zuruckgeliefert) an, zu der eine Schaltsekunde auftritt oder zu der die Schaltsekundentabelle auslauft; der zweite ist eine vorzeichenbehaftete Ganzzahl, die die Korrektur spezifiziert - diese ist die Gesamtzahl an Schaltsekunden, die wahrend der bei der angegeben Zeit beginnenden Zeitperiode angewandt werden soll. Die Wertepaare werden in streng aufsteigender Zeit-Reihenfolge sortiert. Jedes Paar zeigt eine Schaltsekunde an, entweder positiv oder negativ; ausser dass das letzte Paar die Auslaufzeit der Schaltsekundentabelle anzeigt, falls die letzten zwei Paare die gleiche Korrektur tragen. Jede Schaltsekunde ist am Ende des UTC-Kalendermonats. Die erste Schaltsekunde hat eine nicht negative Auftrittzeit und ist eine positive Schaltsekunde falls (und nur falls) ihre Korrektur positiv ist. Die Korrektur fur jede Schaltsekunde nach der ersten unterscheidet sich von der vorherigen Schaltsekunde durch entweder 1 fur eine positive Schaltsekunde oder -1 fur eine negative Schaltsekunde. Falls die Schaltsekundentabelle leer ist, ist die Schaltsekundenkorrektur Null fur alle Zeitstempel; andernfalls ist die Schaltsekundenkorrektur Null fur Zeitstempel vor der ersten Auftrittszeit, falls die Korrektur des ersten Paares 1 oder -1 ist und ist andernfalls nicht spezifiziert (was nur passieren kann, wenn die Datei beim Start abgeschnitten ist). o tzh_ttisstdcnt Standard-/Wall-Kennziffern, jede wird als logischer 1-Byte-Wert gespeichert. Sie geben an, ob die Ubergangszeiten, die den lokalen Zeit-Typen zugeordnet sind, als Standard-Zeit oder als lokale (>>wall clock<<) Zeit angegeben sind. o tzh_ttisutcnt UT-/Lokal-Kennziffern, jede als logischer 1-Byte-Wert gespeichert. Sie besagen, ob die den lokalen Zeit-Typen zugeordneten Ubergangszeiten 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 Ubergangszeiten einer TZif-Datei in geeignete Ubergange fur andere Zeitzonen, die mittels einer POSIX.1-2017-artigen TZ-Zeichenkette ohne Regeln festgelegt wurde, entwickelt. Ist beispielsweise TZ="EET-2EEST" und es gibt keine TZif-Datei "EET-2EEST", dann besteht die Idee darin, die Regeln aus einer TZif-Datei mit dem gut bekannten Namen >>posixrules<< anzupassen, die nur fur diesen Zweck existiert und eine Kopie der Datei >>Europe/Brussels<<, einer Datei mit einem anderen UT-Versatz, ist. POSIX spezifiziert dieses veraltete Ubergangsverhalten nicht, die Standardregeln hangen von der Installation ab und es gibt keine bekannte Implementierung, die diese Funktionalitat fur Zeitstempel nach 2037 implementiert. Um eine bessere historische Abdeckung zu erreichen, wird auf TZ="EET-2EEST,M3.5.0/3,M10.5.0/4" zuruckgefallen, falls POSIX-Konformitat benotigt wird und altere Zeitstempel konnten 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 Ubergangszeitpunkt. Version-2-Format Fur Zeitzonen-Dateien im Version-2-Format folgen dem oben Beschriebenen (Vorspann und Daten) ein zweiter Vorspann und Daten in einem ahnlichen Format. Der Unterschied besteht darin, dass die Ubergangszeiten und Schaltsekundenzeiten jeweils mit jeweils acht Byte kodiert werden (Schaltsekundenzahlen bleiben vier Bytes). Nach dem zweiten Vorspann und den Daten folgt eine durch Zeilenumbruche eingeschlossene Zeichenkette im Stil der Inhalte der POSIX.1-2017-TZ-Umgebungsvariablen. Sie ist fur die Behandlung der Momente nach der letzten in der Datei gespeicherten Ubergangszeit oder fur alle Momente, falls die Datei keine Ubergange enthalt, gedacht. Die TZ-Zeichenkette ist leer (d.h. nichts zwischen den Zeilenumbruchen), falls es keine POSIX.1-2017-artige Darstellung fur solche Momente gibt. Falls nicht leer, muss die TZ-Zeichenkette mit dem lokalen Zeittyp nach der letzten Ubergangszeit, falls diese in den Acht-Byte-Daten vorhanden ist, ubereinstimmen. Falls die letzte Ubergangszeit bei der beispielhaften Zeichenkette "WET0WEST,M3.5.0/1,M10.5.0" im Juli gewesen ist, dann muss der lokale Ubergangszeittyp die Sommerzeit festlegen, die mit "WEST" d.h. eine Stunde ostlich von UT, festgelegt wird. Falls es auch mindestens einen Ubergang gibt, wird der Zeittyp 0 der Zeitperiode von der unendlichen Vergangenheit bis zu, aber nicht einschliesslich der ersten Ubergangszeit zugeordnet. Version-3-Format Fur Zeitzonendateien im Version-3-Format darf die TZ-Zeichenkette zwei kleinere Erweiterungen gegenuber dem POSIX.1-2017-TZ-Format verwenden, wie diese in newtzset(3) beschrieben sind. Zuerst darf der Stundenanteil seiner Ubergangszeiten 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 uber effektiv, falls sie am 1. Januar um 00:00 anfangt und am 31. Dezember um 24:00 endet, plus dem Unterschied zwischen der Sommerzeit und der Standardzeit. Version-4-Format Fur TZif-Dateien im Version-4-Format kann der erste Schaltsekundendatensatz eine Korrektur haben, die weder +1 noch -1 ist, um eine am Anfang abgeschnittene TZif-Datei darzustellen. Falls zwei oder mehr Schaltsekundenubergange vorhanden sind und die letzte Korrektur identisch zu der vorhergehenden ist, dann zeigt auch der letzte Eintrag das Auslaufen der Schaltsekundentabelle an, statt einer Schaltsekunde; Zeitstempel nach diesem Auslaufen sind unzuverlassig dergestalt, dass zukunftige Veroffentlichungen wahrscheinlich Schaltsekundeneintrage nach dem Auslaufen hinzufugen werden und die hinzugefugten Schaltsekunden beeinflussen werden, wie Zeitstempel nach dem Auslaufen behandelt werden. Betrachtungen zur Interoperabilitat In zukunftigen Anderungen des Formats konnen weitere Daten angehangt werden. Version-1-Dateien werden als veraltetes Format betrachtet und sollten nicht erstellt werden, da sie keine Ubergangszeiten nach dem Jahr 2038 unterstutzen. Leseprogramme, die nur Version 1 verstehen, mussen samtliche Daten, die hinter dem berechneten Ende des Version-1-Datenblocks liegen, ignorieren. Anders als bei Version 1 sollten Schreibprogramme die niedrigste fur die Dateidaten benotigte Versionsnummer erstellen. Beispielsweise sollte ein Schreibprogramm nur eine Version-4-Datei erstellen, falls seine Schaltsekundentabelle entweder ablauft oder am Anfang abgeschnitten ist. Entsprechend sollte ein Schreibprogramm, das keine Version-4-Datei erstellt nur eine Version-3-Datei erstellen, falls die TZ-Zeichenkettenerweiterungen notwendig sind, um die Ubergangszeiten genau zu modellieren. Die Sequenz der durch den Version-1-Vorspann und -Datenblock definierten Zeitanderungen sollten eine aufeinanderfolgende Teilfolge von Zeitanderungen sein, die durch Version 2+-Vorspann und -Datenblock und dem Nachspann definiert werden. Diese Richtschnur hilft veralteten Version-1-Leseprogrammen, mit den aktuellen Leseprogrammen uber Zeitstempel innerhalb der aufeinanderfolgenden Teilfolge ubereinzustimmen. Es lasst Schreibprogrammen, die veraltete Leseprogramme nicht unterstutzen, einen tzh_timecnt von Null in dem Version-1-Datenblock verwenden, um Platz zu sparen. Wenn eine TZiF-Datei eine Schaltsekundentabellenablaufzeit enthalt, sollten TZif-Leseprogramme entweder die Verarbeitung von Zeitstempeln nach dem Ablauf verweigern oder sie so verarbeiten, als ob die Ablaufzeit nicht existierte (moglicherweise unter Angabe einer Fehleranzeige). Zeitzonenbezeichnungen sollten aus mindestens drei (3) und nicht mehr als sechs (6) alphanumerischen ASCII-Zeichen bestehen "-", und "+". Dies ist zur Kompatibilitat zu POSIX-Anforderungen fur Zeitzonenabkurzungen. Beim Lesen einer Version 2-Datei oder hoherer sollten Leseprogramme den Version-1-Vorspann und -Datenblock ignorieren und ihn lediglich uberspringen. Leseprogramme sollten als Teil der Gultigkeitsprufung fur die Datei die Gesamtlange der Vorspanne und Datenblocke berechnen und prufen, dass sie alle in die tatsachliche Dateigrosse hineinpassen. Wenn eine positive Schaltsekunde auftritt, sollten Leseprogramme eine zusatzliche Sekunde zu der lokalen Minute, die die Sekunde genau vor der Schaltsekunde enthalt, hinzufugen. Falls dies auftritt, wenn der UTC-Versatz nicht ein Vielfaches von 60 Sekunden ist, dann tritt die Schaltsekunde fruher auf als die letzte Sekunde der lokalen Minute und die verbleibenden lokalen Sekunden werden bis 60 anstatt der gewohnlichen 59 nummeriert; der UTC-Versatz ist davon nicht betroffen. Haufige Interoperabilitatsprobleme Dieser Abschnitt dokumentiert haufige Probleme beim Lesen oder Schreiben von TZif-Dateien. Die meisten Probleme bestehen beim Erstellen von TZif-Dateien fur den Einsatz mit alteren Leseprogrammen. Die Ziele dieses Abschnittes sind: o TZif-Schreibprogrammen bei der Ausgabe von Dateien zu helfen, um haufige Fallstricke in alteren oder defekten TZif-Leseprogrammen zu vermeiden, o TZif-Leseprogrammen dabei zu helfen, haufige Fallstricke beim Lesen von Dateien zu vermeiden, die durch zukunfigte TZif-Schreibprogramme erstellt wurden und o allen zukunftigen Autoren der Spezifikation dabei zu helfen, zu sehen, welche Arten von Problemen auftauchen, wenn das TZif-Format geandert 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 fur eine neuere TZif-Version ist, als fur die das Leseprogramm entwickelt wurde. Wenn eine komplette Kompatibilitat nicht erreicht wurde, wurde versucht, die Storungen auf selten benutzte Zeitstempel zu begrenzen und einfache teilweise Umgehungen in Schreibprogrammen, die fur die Daten der neuen Version entwickelt wurden, selbst fur Leseprogramme alterer Versionen zu erlauben. Interoperabilitatsprobleme mit TZif sind beispielsweise: o Einige Leseprogramme untersuchen nur Daten der Version 1. Als eine teilweise Umgehung kann ein Schreibprogramm so viel Daten in Version 1 wie moglich 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. o Einige fur Version 2 entwickelte Leseprogramme konnten Zeitstempel nach dem letzten Ubergang der Version 3-Datei oder einer hoheren handhaben, da sie keine Erweiterungen gegenuber POSIX.1-2017 in der TZ-artigen Zeichenkette auswerten konnen. Als teilweise Umgehung kann ein Schreibprogramm mehr Ubergange als notwendig ausgeben, so dass nur weit in der Zukunft liegende Zeitstempel von Leseprogrammen der Version 2 falsch gehandhabt werden. o Einige Leseprogramme, die fur Version 2 entwickelt wurden, unterstutzen keine dauerhafte Sommerzeit mit einem Ubergang nach 24:00 -, z.B. eine TZ-Zeichenkette "EST5EDT,0/0,J365/25" , die dauerhafte Eastern Daylight Time (-04) angibt. Als Umgehung kann ein Schreibprogramm als Ersatz die Normalzeit fur zwei Zeitzonen ostlich verwenden, z.B. "XXX3EDT4,0/0,J365/23" fur eine Zeitzone mit einer ganzjahrigen niemals endenden Normalzeit (XXX, -03) und negativer Sommerzeit (EDT, -04). Alternativ kann ein Schreibprogramm als teilweise Umgehung als Ersatz die Normalzeit fur die nachste ostliche Zeitzone verwenden, z.B. "AST4" fur dauerhafte Atlantic Standard Time (-04). o Einige Leseprogramme, die fur Version 2 oder 3 entwickelt wurden und die strenge Konformitat zu RFC 8536 benotigen, lehnen Version-4-Dateien ab, deren Schaltsekundentabelle am Anfang abgeschnitten sind oder die in Ablaufzeiten enden. o Einige Leseprogramme ignorieren den Nachspann und sagen stattdessen zukunftige Zeitstempel vom Zeittyp des letzten Ubergangs her vorher. Als teilweise Umgehung kann ein Schreibprogramm mehr Ubergange als notwendig ausgeben. o Einige Leseprgoramme verwenden nicht den Zeittyp 0 fur Zeitstempel vor dem ersten Ubergang, sondern erschliessen sich den Zeittyp mittels einer Heuristik, die nicht immer den Zeittyp 0 auswahlt. Als teilweise Umgehung kann ein Schreibprogramm einen unechten (no-op) ersten Ubergang zu einem fruheren Zeitpunkt ausgeben. o Einige Leseprogramme handhaben Zeitstempel vor dem ersten Ubergang, die einen Zeitstempel mit nicht weniger als -2**31 haben, falsch. Leseprogramme, die nur 32-Bit-Zeitstempel unterstutzen, sind wahrscheinlich anfalliger fur dieses Problem, beispielsweise wenn sie 64-Bit-Ubergange verarbeiten, die nur teilweise in 32 Bit darstellbar sind. Als eine mogliche Umgehung kann ein Schreibprogramm unechte Ubergange beim Zeitstempel -2**31 ausgeben. o Einige Leseprogramme handhaben Ubergange falsch, falls ihre Zeitstempel den minimal moglichen 64-Bit-Wert haben. Zeitstempel kleiner -2**59 werden nicht empfohlen. o Einige Leseprogramme handhaben TZ-Zeichenketten falsch, die Folgendes enthalten: "<" oder ">". Als teilweise Umgehung kann ein Schreibprogramm vermeiden, "<" oder ">" fur Zeitzonenabkurzungen zu verwenden, die nur alphabetische Zeichen enthalten. o Viele Leseprogramme handbaben Zeitzonenabkurzungen, die andere als ASCII-Zeichen enthalten, falsch. Diese Zeichen werden nicht empfohlen. o Einige Leseprogramme konnten Zeitzonenabkurzungen, die weniger als 3 und mehr als 6 Zeichen oder nichtalphanumerische ASCII-Zeichen enthalten, falsch handhaben. "-", und "+". Diese Abkurzungen werden nicht empfohlen. o Einige Leseprogramme handhaben TZif-Dateien falsch, die einen Sommerzeit-UT-Versatz festlegen, der kleiner als der UT-Versatz fur die entsprechende Standardzeit ist. Diese Leseprogramme unterstutzen Orte wie Irland nicht, die das Aquivalent zu der 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 fur das Aquivalent der 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-Versatze und Zeitzonenabkurzungen korrekt auf. o Einige Leseprogramme erstellen uneindeutige Zeitstempel fur positive Schaltsekunden die auftreten, wenn der UTC-Versatz kein Vielfaches von 60 Sekunden ist. Beispielsweise werden einige Leseprogramme in einer Zeitzone mit UTC-Versatz +01:23:45 und mit einer positiven Schaltsekunde 78796801 (1972-06-30 23:59:60 UTC) sowohl 78796800 als auch 78796801 auf 01:23:45 lokale Zeit am nachsten Tag abbilden, statt letzteres auf 01:23:46 abzubilden und daher 78796815 auf 01:23:59 anstatt auf 01:23:60 abzubilden. Dies war bisher kein praktisches Problem, da bisher keine Behorde einen solchen UTC-Versatz beobachtet hat, seit Schaltsekunden 1972 eingefuhrt wurden. Einige Interoperabilitatsprobleme sind Fehler von Leseprogrammen, die hier hauptsachlich als Warnung an Entwickler von Leseprogrammen aufgefuhrt sind. o Einige Leseprogramme unterstutzen keine negativen Zeitstempel. Entwickler von verteilten Anwendungen sollten dies im Hinterkopf behalten, falls sie mit Daten vor 1970 umgehen mussen. o Einige Leseprogramme handhaben Zeitstempel vor dem ersten Ubergang, der einen nichtnegativen Zeitstempel hat, falsch. Leseprogramme, die keine negativen Zeitstempel unterstutzen, sind wahrscheinlich anfalliger fur dieses Problem. o Einige Leseprogramm handhaben Zeitzonenabkurzungen wie "-08" die "+", "-", oder Ziffern enthalten. o Einige Leseprogramme handhaben UT-Versatze, die ausserhalb des traditionellen Bereichs von -12 bis 12 Stunden sind, nicht korrekt, und unterstutzen damit Orte wie Kiritimati, die ausserhalb dieses Bereichs liegen, nicht. o Einige Leseprogramme handhaben UT-Versatze im Bereich [-3599, -1] Sekunden von UT nicht korrekt, da sie eine Ganzzahldivision des Versatzes durch 3600 durchfuhren, um 0 zu erhalten, und dann den Stundenanteil wie folgt anzeigen: "+00". o Einige Leseprogramme handhaben UT-Versatze 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 doi:10.17487/RFC8536 . UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer , Helge Kreutzmann und Mario Blattermann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Zeitzonen-Datenbank tzfile(5)