Ist meine BST-Zeitzone eine Stunde zurück?

Question 1

BSTwird nicht als Zeitzonenname erkannt. Es wird in der Ausgabe als Abkürzung verwendet, kann aber nicht zur Bezeichnung einer Zeitzone verwendet werden. Die meisten Programme überprüfen Zeitzonennamen nicht und verwenden stillschweigend GMT, wenn der Zeitzonenname nicht erkannt wird.

Abkürzungen wie BST, CET, EST usw. sind nicht immer eindeutig definiert und manchmal mehrdeutig (ist es die nordamerikanische oder australische Eastern Standard Time?). Sie sind nur in einer bestimmten Region sinnvoll, während die Zeitzonenkonfiguration normalerweise für den weltweiten Gebrauch vorgesehen ist. Darüber hinaus bezeichnet eine Abkürzung wie BST nicht wirklich eine Zeitzone, sondern nur die Zeit, die für einen Teil des Jahres in einer bestimmten Zeitzone herrscht (Großbritannien während der Sommerzeit). Sie sollten also eindeutige Bezeichnungen verwenden, von denen die meisten dem Muster Kontinent/Stadt folgen. Auf typischen Linux-Systemen und ich denke auch auf vielen anderen Unix-Varianten können Sie sehen, welche Abkürzungen verfügbar sind, indem Sie im Verzeichnis nachsehen /usr/share/zoneinfo.

Verwenden Sie also statt GMTim Winter und BSTim Sommer Europe/London.

Answer

BSTwird nicht als Zeitzonenname erkannt. Es wird in der Ausgabe als Abkürzung verwendet, kann aber nicht zur Bezeichnung einer Zeitzone verwendet werden. Die meisten Programme überprüfen Zeitzonennamen nicht und verwenden stillschweigend GMT, wenn der Zeitzonenname nicht erkannt wird.

Abkürzungen wie BST, CET, EST usw. sind nicht immer eindeutig definiert und manchmal mehrdeutig (ist es die nordamerikanische oder australische Eastern Standard Time?). Sie sind nur in einer bestimmten Region sinnvoll, während die Zeitzonenkonfiguration normalerweise für den weltweiten Gebrauch vorgesehen ist. Darüber hinaus bezeichnet eine Abkürzung wie BST nicht wirklich eine Zeitzone, sondern nur die Zeit, die für einen Teil des Jahres in einer bestimmten Zeitzone herrscht (Großbritannien während der Sommerzeit). Sie sollten also eindeutige Bezeichnungen verwenden, von denen die meisten dem Muster Kontinent/Stadt folgen. Auf typischen Linux-Systemen und ich denke auch auf vielen anderen Unix-Varianten können Sie sehen, welche Abkürzungen verfügbar sind, indem Sie im Verzeichnis nachsehen /usr/share/zoneinfo.

Verwenden Sie also statt GMTim Winter und BSTim Sommer Europe/London.

Question 2

Wie @Gilles sagte, ist BST etwas, das bei date/ ausgegeben wird date +%Z, um den Benutzern mitzuteilen, dass es sich um ein Datum der britischen Sommerzeit (also GMT+1) handelt. Es ist nichts, das eine Zeitzone definiert, und nichts, das Sie für verwenden können $TZ.

Diese BST ist für britische Benutzer von Bedeutung. Wenn ein britischer Benutzer sieht 14:00 BST, weiß er, dass sich der Zeitstempel auf 14:00 Uhr Sommerzeit auf dem britischen Festland bezieht (also 13:00 Uhr UTC). Die Verwendung dieser 3-4-stelligen Codes ist in Großbritannien, den USA und einigen anderen englischsprachigen Ländern weit verbreitet und wird daher in der Standardausgabe von datedort angezeigt (z. B. in en_GB.UTF-8Gebietsschemas). Andererseits werden die meisten französischen Benutzer keine Ahnung haben, was 14:00 CESTbedeutet (obwohl CESTsich bezieht aufMitteleuropäische Sommerzeit, die GMT+2, die im Sommer in Frankreich gilt), daher werden Sie feststellen, dass Datumsangaben bei der Angabe der Zeitzone eher die UTC-Verschiebung als CET/ CESTdort (wie mardi 2 mai 2017, 13:34:09 (UTC+0200)) enthalten.

Die $TZVariable soll nicht diese 3-4-stelligen Codes enthalten. Sie enthält etwas, dasdefiniert/gibt andie Zeitzone, die Region, in der Sie sich befinden. Anwendungen nutzen diese Daten, um zu jedem Zeitpunkt die Abweichung von der UTC zu kennen, um zwischen Winter- und Sommerzeit umzuschalten und um zu sehen, welcher Code (sofern vorhanden) für die Winter- bzw. Sommerzeit dem Benutzer angezeigt wird (für Benutzer, für die dies von Bedeutung ist).

Dazu können Sie entweder TZeine systemdefinierte Zeitzonenspezifikation festlegen TZ=:Europe/London(obwohl viele Systeme dies auch akzeptieren TZ=Europe/London) oder TZdie vollständigen Regeln einhalten (obwohl diese Regeln begrenzt sind).

Wenn ich beispielsweise TZ=:Europe/Londonauf meinem System verwende, werden die Regeln von gelesen /usr/share/zoneinfo/Europe/London.

Diese Datei gibt beispielsweise an, dass seit 1996 der Offset von UTC vom letzten Sonntag im Oktober um 2 Uhr UTC bis zum letzten Sonntag im März 0 beträgt (mit dem Namen GMT für "Greenwich Mean Time") und ansonsten 1 (mit dem Namen BST für "British Summer Time"), während er von 1970 (0 Unix-Zeit) bis 1972 das ganze Jahr über 1 betrug (mit dem Namen BST für "BritishStandardZeit".

Sie sehen bereits, dass es keinen Sinn ergibt, BST als Zeitzonenangabe zu verwenden. Erstens hat es zu verschiedenen Zeitpunkten unterschiedliche Bedeutungen, und selbst wenn wir nur die aktuelle Epoche betrachten, ist es nur ein Code für die Sommerzeit und kann daher nicht als Zeitzonenangabe für das ganze Jahr verwendet werden.

Nun können Sie auch TZdie vollständigen Regeln enthalten. Für die „British Standard (not Summer) Time“ der frühen 70er Jahre können Sie beispielsweise die einfachste Form der Spezifikation verwenden:

TZ=BST-1

Damit wird eine Zeitzone festgelegt, die immer 1 Stunde östlich von UTC liegt und für die date +%Zimmer zurückgegeben wird BST. Diese Zeitzone ist für das britische Festland seit Anfang der 70er Jahre und für die Sommerzeit seit 1972 korrekt, seit 1972 jedoch nicht mehr für die Winterzeit (und für die Zukunft können wir es nicht vorhersagen).

Oder Sie nutzen die vollständige Spezifikation der aktuellen Regeln:

TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00

Dies bedeutet, dass es zwei Zeiträume im Jahr gibt, einen mit der Bezeichnung GMT mit Offset 0 und einen BST mit Offset 1 (oben impliziert 0+1, wenn nicht anders angegeben). Die Umstellung von einem zum anderen erfolgt am letzten (5) Sonntag (0) im März (3) um 1:00:00 UTC und zurück am letzten Sonntag im Oktober um 2:00.

Auch hier gilt, dass die TZ von 1996 bis heute funktioniert, aber nicht unbedingt anders. Zum Beispiel für den 1. Januar 1970, 00:00:00 UTC (Unix-Epochenzeit 0, als die Ortszeit in London 1:00:00 BST (British Standard Time) war):

$ TZ=:Europe/London date -d @0
Thu  1 Jan 01:00:00 BST 1970
$ TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00 date -d @0
Thu  1 Jan 00:00:00 GMT 1970

Pro POSIX, das Verhalten für

TZ=BST-1ist gut definiert (wie oben beschrieben)
TZ=BST(oder TZ=GMT/ TZ=UTC/ TZ=Europe/London) ist nicht angegeben.
TZ=:BST/ TZ=:Europe/LondonIstImplementierung definiert. Das heißt, Systeme sollen dies unterstützen und dokumentieren, was es bewirkt, obwohl POSIX uns nicht sagt, was es bewirkt.

Im dritten Fall oben wird auf GNU-Systemen (und ich glaube, auf den meisten anderen Unix-ähnlichen Systemen) das Folgende als Pfad zu einer Zeitzonendefinitionsdatei verwendet, wenn TZmit einem beginnt . Im Fall von GNU-Systemen ist dies auch der Fall, wenn weggelassen wird (selbst wenn der Wert eine gültige Zeitzonenspezifikation wie darstellt , aber im Allgemeinen sollten solche Dateien nicht existieren, obwohl ich auf meinem System einige Ausnahmen sehe, die es zu einem Nicht-POSIX-System machen (zum Beispiel gibt es statt aus , weil es eine Datei ¹ gibt , die eine definiert::UTC0TZ=CST6CDT date -d 1943-01-01 +%ZCWTCST/usr/share/zoneinfo/CST6CDTKriegszeitfür diesen Zeitraum)).

Dieser Pfad ist im Allgemeinen ein relativer Pfad. In diesem Fall ist er relativ zu $TZDIR(oder zu einem Standardwert, z. B. /usr/share/zoneinfowenn $TZDIRer nicht festgelegt ist, was im Allgemeinen der Fall ist). Aus Sicherheitsgründen werden $TZDIRabsolute Pfade oder relative Pfade mit ..Komponenten in Kontexten mit Berechtigungsausweitung (wie in Setuid-Kontexten) ignoriert.

Auf einem GNU-System sucht also normalerweise ein TZ=:BST, identisch mit TZ=BSTnach einer /usr/share/zoneinfo/BSTDatei. Wenn diese nicht gefunden wird (was der Fall wäre, wenn BSTeine Zeitzonendefinition nicht identifiziert werden kann), wird normalerweise die UTC-Zeit und der Zeitzonenname (wie in der date +%ZAusgabe) von angenommen BST.

¹ Solche CST6CDTwie WET, CET, MET... sind Überbleibsel aus einer anderen Zeit. Ende 1993 wurde die TZ-Datenbank (wie heuteverwaltet von IANA)geändertvon der Verwendung von Ad-hoc-Namen (und meist mehrdeutigen Namen) (wie MET, GB-Eire, WET) bis hin zu Area/CityNamen, bei denen es sich bei der Stadt um die bevölkerungsreichste Stadt (zum Zeitpunkt der Veröffentlichung) handelt, für die die Zone gilt (Bereich sind große Gebiete wie Kontinent/Ozean). Für das britische Festland, wo Sie früher GB-Eire(nicht WET) verwendet haben, verwenden Sie jetzt (seit 1993) Europe/London. GB-Eire(wie WET) sind aus Gründen der Abwärtskompatibilität weiterhin verfügbar ( GB-Eireverlinkt jetzt auf Europe/London, während WETals Zone mit UTC im Winter und den EU-Regeln für die Sommerzeit definiert ist (Großbritannien befolgt die EU-Regeln erst seit 1996, und da das Vereinigte Königreich jetzt die EU verlässt, kann niemand vorhersagen, was die Zukunft bringt)), sollten aber jetzt nicht mehr in neuen Bereitstellungen verwendet werden.

Answer