したがって、なぜこれが起こるのか理解したいと思います（単純化）。

$ TZ=MET date; TZ=MET+0 date
Tue 01 Jun 2021 06:00:00 AM MEST
Tue 01 Jun 2021 04:00:00 AM MET

METつまり、との差は2時間ですMET+0。

この問題をデバッグする最も簡単な方法は、'+%z'書式を追加することです。結果の印刷に使用された日付オフセットを印刷し、問題のある場所をデバッグするのに役立ちます。

$ TZ=MET date "+%c %z"; TZ=MET+0 date "+%c %z"
Wed 31 Mar 2021 06:11:16 PM MEST +0200
Wed 31 Mar 2021 04:11:16 PM MET +0000

-2これは、日付がオフセットとオフセットの結果を印刷していることを示します+0。

質問は次のとおりです。なぜ？

それはおそらく、TZの最初の形式がstd offset（TAG-03に似ていたからです）。POSIX リファレンス）の中商標標準領域の範囲を定義し、そのラベルに対するオプションのオフセットを提供します。欠落している場合はオフセットが想定されます+0。

したがって、METをMETに設定nameし、オフセットを+ 0に設定しました。

証明する:

$ TZ=MET date "+%c %z"; TZ=METX+7:30 date "+%c %z"
Wed 31 Mar 2021 06:19:00 PM MEST +0200
Wed 31 Mar 2021 08:49:00 AM METX -0730

これ商標簡単です。印刷するタイムゾーン名。

そのようなラベルに使用されるオフセットは次のとおりです。 （-7:30質問なし）

METXそのようなラベルはどこにもなく、ラベルに7:30オフセットもないことが明らかになります。

これは、aがラベルと昨日のオフセットをMET+24使用してタイムゾーンの時間を印刷する理由を説明します（必要に応じて試してください）。MET+0+24+12

正しいTZ

私達はTZをテストできます説明する標準時間は7時間、夏時間は9時間です。MET-7MEST-9。テストするには、以下を印刷するためのfaketime（Solaris用にコンパイルする必要があります）が必要です。

$ # In January (no DST):
$ faketime "1/1/21 12:00" bash -c 'date -u; TZ=MET date "+%c %z"'; \
  faketime "1/1/21 12:00" bash -c 'TZ=MET-7MEST-9  date "+%c %z"'

Fri 01 Jan 2021 04:00:00 PM UTC
Fri 01 Jan 2021 05:00:00 PM MET +0100
Fri 01 Jan 2021 11:00:00 PM MET +0700

$ # In June (DST in effect)
$ faketime "6/1/21 12:00" bash -c 'date -u; TZ=MET date "+%c %z"'; \
  faketime "6/1/21 12:00" bash -c 'TZ=MET-7MEST-9  date "+%c %z"'

Tue 01 Jun 2021 04:00:00 PM UTC
Tue 01 Jun 2021 06:00:00 PM MEST +0200
Wed 02 Jun 2021 01:00:00 AM MEST +0900

これは私たちの分析を確認することだけです。 TZ値は次のように減らすことができます。MET-7MESTDSTの基本効果は時間を1時間増やすことだからです。また、METの実際のUTCオフセットは+1なので、TZは次のようにする必要があると判断できます。MET-1MEST。 dstマーカー（MET-1）が欠落している場合、dstオフセットは適用されません。

あなたのための時間目標の設定昨日（+24時間）以下を使用する必要があります。

TZ='MET+23MEST'

質問？