私のBSTタイムゾーンは1時間遅れていますか？
私のシステム（Debian TestingのGnome 3）は現在の時刻について混乱しています。 dateを実行すると、時刻は正しく表示されますが、一部のアプリケーションは1時間遅れています。たとえば、Gnomeカレンダーにイベントを追加すると、カレンダーの予定に表示されるイベント時間は、入力した時間から1時間を引いたものになります。
私は問題が何であるかを見つけましたが、それを解決する方法がわかりません：
$ date ; TZ=GMT date ; TZ=BST date
Sun 30 Apr 11:25:37 BST 2017
Sun 30 Apr 10:25:37 GMT 2017
Sun 30 Apr 10:25:37 BST 2017
出力の最初の2行は正しく、3行目は1時間遅れています。私が理解できないのは、BSTタイムゾーンが1時間遅れているように見えるのに、現在の時刻が正しく、BSTを使用している理由です。
これも関連している可能性があります。
$ timedatectl status
Local time: Sun 2017-04-30 11:33:07 BST
Universal time: Sun 2017-04-30 10:33:07 UTC
RTC time: Sun 2017-04-30 10:33:07
Time zone: Europe/London (BST, +0100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
編集 zdump/etc/localtimeの出力：
$ zdump /etc/localtime
/etc/localtime Sun Apr 30 12:22:53 2017 BST
$ date ; TZ=GMT date ; TZ=BST date
Sun 30 Apr 12:22:53 BST 2017
Sun 30 Apr 11:22:53 GMT 2017
Sun 30 Apr 11:22:53 BST 2017
Gillesの回答を補完する。 OPと同じタイムゾーンにいます。西ヨーロッパ時間（WET）は正式な名称です。メモリに問題がなければ、1996年頃のUnixタイムゾーンのポルトガルに含まれていました。
https://en.wikipedia.org/wiki/Western_European_Time
ヨーロッパ時間（WET、UTC±00：00）は、西ヨーロッパおよび北西ヨーロッパの一部をカバーするタイムゾーンです。
次の国と地域では、冬季にWETを使用します。
-カナリア諸島、> 1946年以降（スペインの残りはCET、UTC + 1）-フェロー諸島、1908年以降
-北東グリーンランド（デンマークとその周辺）
-アイスランド、1968年以来
-ポルトガル、1912年以降、一時停止あり（アゾレス、UTC-1を除く）[1]
-マデイラ諸島、1912年以降、一時停止あり[2]
-アイルランド、1968年から1971年までを除いて1916年から（正式にはグリニッジ標準時として知られています）
-イギリスとクラウンの依存関係、1847年以降のイングランド、スコットランド、ウェールズ、チャネル諸島、マン島、および1916年以降の北アイルランド（正式にはグリニッジ標準時として知られています）、一時停止ありイギリスでは、1940年から1945年までのイギリスの夏時間（BST = CET）が冬に使用され、1941年から1945年まで、そして1947年のイギリスの夏時間（BDST = CEST）が夏に使用されました。 1968年2月18日から1971年10月31日まで、BSTは一年中使用されました。
アイスランドを除く上記の国はすべて夏時間に夏時間を実装し、西ヨーロッパ夏時間（WEST、UTC + 1）に切り替えます。これはWETより1時間進んでいます。 WESTは英国では英国夏時間と呼ばれ、正式にはアイルランドではアイルランド標準時として知られています。
夏時間の公式名称はWEST（西ヨーロッパ夏時間）ですが、WETはTZに使用され、夏時間/ DSTを考慮して1時間進みます。
「ヨーロッパ/ロンドン」の方が良い選択かもしれませんが、WET省略形を知っていることは、状況によってはまだ役に立ちます。
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
したがって、結果を最初のテストと比較するには：
$date ; TZ=GMT date ; TZ=WET date
Mon May 1 09:36:10 WEST 2017
Mon May 1 08:36:10 GMT 2017
Mon May 1 09:36:10 WEST 2017
BSTはタイムゾーン名として認識されません。出力の省略形として使用されますが、タイムゾーンの指定には使用できません。ほとんどのプログラムはタイムゾーン名をチェックせず、タイムゾーン名が認識されない場合は黙ってデフォルトでGMTに設定されます。
BST、CET、ESTなどの省略形は、必ずしも明確に定義されているわけではなく、あいまいな場合もあります（北米またはオーストラリアの東部標準時ですか？）。これらは特定の地域でのみ意味がありますが、タイムゾーン構成は通常、世界中で使用することを目的としています。さらに、BSTのような略語は実際にはタイムゾーンを指定するのではなく、年の一部の特定のタイムゾーンにある時間のみを示します（夏時間が有効なイギリス）。したがって、明確な指定を使用する必要があります。そのほとんどは大陸/都市のパターンに従います。典型的なLinuxシステム、および他の多くのUnixバリアントでも、ディレクトリ/usr/share/zoneinfoを調べることで、使用可能な略語を確認できます。
したがって、冬にはGMTを使用し、夏にはBSTを使用する代わりに、Europe/Londonを使用します。
@Gillesが言ったように、BSTはdate/_date +%Z_に出力されるものであり、英国夏時間の日付（つまりGMT + 1）であることをタイムゾーンを定義するものではなく、使用できるものではないことをユーザーに伝えます_$TZ_の場合。
そのBSTはイギリスのユーザーにとって重要です。イギリスのユーザーが_14:00 BST_を見ると、タイムスタンプがイギリス本土の夏時間の14:00（つまり13:00 UTC）を指していることがわかります。これらの3〜4文字のコードの使用はイギリス、アメリカ、およびその他の英語圏の国々で広く行われているため、dateのデフォルトの出力（たとえば、_en_GB.UTF-8_ロケール）に表示されます。一方、ほとんどのフランスのユーザーは、_14:00 CEST_の意味がわかりません（CESTは中央ヨーロッパ夏時間、夏に適用されるGMT + 2を指します）フランスでは）、日付がタイムゾーンを指定する場合、CET/CESTではなくUTCオフセットが含まれることに注意してください（mardi 2 mai 2017, 13:34:09 (UTC+0200)など）。
_$TZ_変数は、これらの3〜4文字のコードを含むことを意図していません。 defines/specifysタイムゾーン、現在の地域です。アプリケーションはこれを使用してUTCでのオフセットを認識します任意の時点で、冬時間と夏時間を切り替えるタイミングと、冬時間と夏時間のコード（存在する場合）がユーザーに表示される内容（重要なユーザー）。
そのためには、TZをシステム定義のタイムゾーン指定に設定できます。 _TZ=:Europe/London_のように（ただし、多くのシステムは_TZ=Europe/London_も受け入れます）、またはTZに完全なルールを含めます（これらのルールは制限されています）。
たとえば、システムで_TZ=:Europe/London_を使用すると、ルールは_/usr/share/zoneinfo/Europe/London_から読み取られます。
そのファイルは、たとえば1996年以降、UTCからのオフセットが10月の最後の日曜日の午前2時（UTC）から3月の最後の日曜日まで（「グリニッジ標準時」の名前はGMT）、0はそれ以外（BSTという名前）であることを指定します。 「ブリティッシュサマータイム」の場合）、1970年（0 Unix時間）から1972年までは、「BritishStandardTime」の名前はBSTで、通年1でした。
タイムゾーン仕様としてBSTを使用しても意味がないことがすでにおわかりでしょう。最初に、それは異なる時点で異なることを意味し、現在のエポックのみを考慮しても、それは夏時間のコードにすぎないため、通年のタイムゾーン仕様として使用することはできません。
これで、TZに完全なルールを含めることもできます。たとえば、70年代前半の「英国標準時（夏ではありません）」の場合、最も単純な形式の指定を使用できます。
_TZ=BST-1
_これは、常にUTCの1時間東にあり、_date +%Z_が常にBSTを返すタイムゾーンを指定します。そのタイムゾーンは、70年代前半のイギリス本土と1972年以降の夏時間には当てはまりますが、1972年以降の冬時間には当てはまりません（将来についてはわかりません）。
または、現在のルールの完全な仕様を使用できます。
_TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00
_つまり、1年に2つの期間があり、1つはオフセット0のGMTで、もう1つはオフセット1のBSTです（指定されていない場合は上記の0 + 1として示されます）。 3月の最終（5）日曜日（0）（3）1:00:00 UTC、10月の最終日曜日の2:00に戻ります。
繰り返しますが、そのTZは1996年から現在まで機能しますが、それ以外の場合は必ずしも機能しません。たとえば、1970-01-01 00:00:00 UTC（現地時間がロンドンの1:00:00 BST（英国標準時）だった場合、0 Unixエポック時間）の場合：
_$ 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
_POSIXごと 、の動作
- _
TZ=BST-1_は明確に定義されています（上記のとおり） - _
TZ=BST_（または_TZ=GMT_/_TZ=UTC_/_TZ=Europe/London_）は指定されていません。 - _
TZ=:BST_/_TZ=:Europe/London_は実装定義です。これは、システムがそれをサポートし、それが何をするかを文書化することを目的としています。
上記の3番目のケースでは、GNUシステム（および他のほとんどのUnixライクなシステム）で、TZが_:_で始まる場合、その後のパスがタイムゾーン定義ファイル。GNUシステムの場合、_:_が省略されている場合も同様です（値が_UTC0_のような有効なタイムゾーン指定を形成している場合でも）しかし、通常、そのようなファイルは存在すべきではありませんが、システム上でPOSIX以外のシステムになるいくつかの例外が発生する可能性があります（たとえば、_TZ=CST6CDT date -d 1943-01-01 +%Z_ファイルがあるため、_/usr/share/zoneinfo/CST6CDT_はCWTではなくCSTを出力します1その時間の戦争時間を定義します））。
そのパスは通常、相対パスです。この場合、_$TZDIR_（または、_/usr/share/zoneinfo_が設定されていない場合の_$TZDIR_のようなデフォルトが一般的です）に相対的です。セキュリティ上の理由から、_$TZDIR_、絶対パス、または_.._コンポーネントを使用した相対パスは、特権エスカレーションコンテキスト（setuidコンテキストなど）では無視されます。
したがって、通常、GNU=システムでは、_TZ=:BST_と同じ_TZ=BST_は、通常_/usr/share/zoneinfo/BST_ファイルを探します。見つからない場合（その場合、BSTはタイムゾーン定義を識別できない可能性があるため、通常、BSTのUTC時間とタイムゾーン名（_date +%Z_出力など）を想定します。
1WET、CET、MET...のような_CST6CDT_は、別の時代の名残です。 1993年後半に、TZデータベース（現在の IANAによって維持 ） 変更 は、アドホック（およびほとんどの場合はあいまいな）名（MET、_GB-Eire_、WETなど）の使用から）を_Area/City_に変更します。この都市は、ゾーンが適用される（リリース時の）最も人口の多い都市です（領域は大陸/海などの大きな領域です）。かつて_GB-Eire_（WETではない）を使用していたイギリス本土では、現在（1993年以降）_Europe/London_を使用しています。 _GB-Eire_（WETなど）は下位互換性のために引き続き利用できます（_GB-Eire_は_Europe/London_にリンクするようになりましたが、WETは冬のUTCを使用するゾーンとして定義され、DSTのEU規則（英国では1996年以来EUの規則に従っているだけであり、英国がEUを去った今、誰も未来がどうなるかを言うことはできませんが））新しい展開では現在使用すべきではありません。