Provided by: manpages-de_4.27.0-1_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 2021 entweder ein ASCII NUL “2”, “3”,
oder “4”).
• 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.1-2017-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-Einträgen 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 Ü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_charcnt bytes, die das Zeitzonen-Ziel (Byte-Zeichenketten, die mit NULL enden) darstellen,
jeweils durch die oben erwähnten tt_desigidx-Werte indiziert. Die Byte-Zeichenketten können sich
überlappen, falls eine an eine andere angehängt ist. Die Kodierung dieser Zeichenketten ist nicht
spezifiziert.
• 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) zurückgeliefert) an, zu der eine
Schaltsekunde auftritt oder zu der die Schaltsekundentabelle ausläuft; der zweite ist eine
vorzeichenbehaftete Ganzzahl, die die Korrektur spezifiziert - diese ist die Gesamtzahl an
Schaltsekunden, die während 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; außer 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 für jede Schaltsekunde nach der ersten unterscheidet sich von der vorherigen
Schaltsekunde durch entweder 1 für eine positive Schaltsekunde oder -1 für eine negative
Schaltsekunde. Falls die Schaltsekundentabelle leer ist, ist die Schaltsekundenkorrektur Null für
alle Zeitstempel; andernfalls ist die Schaltsekundenkorrektur Null für 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).
• 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.1-2017-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(3) 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 der Inhalte der POSIX.1-2017-TZ-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 TZ-Zeichenkette ist leer (d.h. nichts zwischen den
Zeilenumbrüchen), falls es keine POSIX.1-2017-artige Darstellung für solche Momente gibt. Falls nicht
leer, muss die TZ-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/1,M10.5.0” 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 TZ-Zeichenkette zwei kleinere Erweiterungen gegenüber
dem POSIX.1-2017-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.
Version-4-Format
Für 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
Schaltsekundenübergänge 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 unzuverlässig dergestalt, dass zukünftige Veröffentlichungen
wahrscheinlich Schaltsekundeneinträge nach dem Auslaufen hinzufügen werden und die hinzugefügten
Schaltsekunden beeinflussen werden, wie Zeitstempel nach dem Auslaufen behandelt werden.
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 nicht erstellt 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.
Anders als bei Version 1 sollten Schreibprogramme die niedrigste für die Dateidaten benötigte
Versionsnummer erstellen. Beispielsweise sollte ein Schreibprogramm nur eine Version-4-Datei erstellen,
falls seine Schaltsekundentabelle entweder abläuft 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 Übergangszeiten genau zu modellieren.
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.
Wenn eine TZiF-Datei eine Schaltsekundentabellenablaufzeit enthält, sollten TZif-Leseprogramme entweder
die Verarbeitung von Zeitstempeln nach dem Ablauf verweigern oder sie so verarbeiten, als ob die
Ablaufzeit nicht existierte (möglicherweise unter Angabe einer Fehleranzeige).
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-Datei oder höherer 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.
Wenn eine positive Schaltsekunde auftritt, sollten Leseprogramme eine zusätzliche Sekunde zu der lokalen
Minute, die die Sekunde genau vor der Schaltsekunde enthält, hinzufügen. Falls dies auftritt, wenn der
UTC-Versatz nicht ein Vielfaches von 60 Sekunden ist, dann tritt die Schaltsekunde früher auf als die
letzte Sekunde der lokalen Minute und die verbleibenden lokalen Sekunden werden bis 60 anstatt der
gewöhnlichen 59 nummeriert; der UTC-Versatz ist davon nicht betroffen.
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 oder einer höheren handhaben, da sie keine Erweiterungen gegenüber POSIX.1-2017 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
mit einem Übergang 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
für zwei Zeitzonen östlich verwenden, z.B. “XXX3EDT4,0/0,J365/23” für eine Zeitzone mit einer
ganzjährigen niemals endenden Normalzeit (XXX, -03) und negativer Sommerzeit (EDT, -04). Alternativ
kann ein Schreibprogramm als teilweise Umgehung als Ersatz die Normalzeit für die nächste östliche
Zeitzone verwenden, z.B. “AST4” für dauerhafte Atlantic Standard Time (-04).
• Einige Leseprogramme, die für Version 2 oder 3 entwickelt wurden und die strenge Konformität zu RFC
8536 benötigen, lehnen Version-4-Dateien ab, deren Schaltsekundentabelle am Anfang abgeschnitten
sind oder die in Ablaufzeiten enden.
• 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 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 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 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 Leseprogramme erstellen uneindeutige Zeitstempel für 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 nächsten 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 Behörde einen solchen
UTC-Versatz beobachtet hat, seit Schaltsekunden 1972 eingeführt wurden.
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
doi: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 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.
Zeitzonen-Datenbank tzfile(5)