Provided by: manpages-de_4.21.0-2_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 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⟩.