oracular (5) tzfile.5.gz

Provided by: manpages-de_4.23.1-1_all bug

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