内蔵のデバイスでは、太平洋標準時（PST）のタイムゾーンがワシントンより1時間早いという苦情を受けました。タイムゾーンを設定するためにtzユーティリティを使用しています。
これはロサンゼルスタイムゾーン:
2018 Sun, Mar 11 at 2:00 am PST → PDT +1 hour (DST start) UTC-7h
Sun, Nov 4 at 2:00 am PDT → PST -1 hour (DST end) UTC-8h
tzユーティリティを最新の2018バイナリに更新しても、この問題はまだ発生します。私が逃した他のものはありますか？
4月1日PST-PDTの変更を確認した後、混乱していますか？
usr/share/zoneinfo # date 031111002018; TZ='America/Los_Angeles' date
Sun Mar 11 11:00:00 UTC 2018
Sun Mar 11 03:00:00 PST 2018
/usr/share/zoneinfo # date 041111002018; TZ='America/Los_Angeles' date
Wed Apr 11 11:00:00 UTC 2018
Wed Apr 11 04:00:00 PDT 2018 <--- Here UTC-7 to UTC-8
PST->PDTが4月1日午前2時に変更されます。
/usr/share/zoneinfo # date 040110242018; TZ='America/Los_Angeles' date
Sun Apr 1 10:24:00 UTC 2018
Sun Apr 1 03:24:00 PDT 2018
ベストアンサー1
Pacific-Newあなたのデバイスが米国で法律で制定されたことはなく、4月の最初の日曜日に夏時間に切り替えることを指定する提案されたタイムゾーンであるタイムゾーンを使用しているようです。
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
## Rule Twilite XXXX max - Apr Sun>=1 2:00 1:00 D
## Rule Twilite XXXX max uspres Oct lastSun 2:00 1:00 PE
## Rule Twilite XXXX max uspres Nov Sun>=7 2:00 0 S
## Rule Twilite XXXX max nonpres Oct lastSun 2:00 0 S
さまざまな理由で、一部のシステムは歴史的に正しい太平洋タイムゾーンの代わりにこのタイムゾーンを使用していました。このリスクレポート（1992年から！）またはこの Debian エラー（2016年以降）を例に挙げます。 2018年の最初のリリースには、tzdata一部のシステムで問題を引き起こす可能性があるいくつかの問題があります。 ~から2018cリリースノート:
デフォルトのインストールプロセスは以前のバージョンとの互換性リンクを生成しなくなり、
US/Pacific-Newユーザー設定中に混乱を招く可能性があります（たとえば、Debianバグ815200を参照）。とにかく、make BACKWARD="backward pacificnew"リンクを作成するために使用します。結局、私たちはリンクを完全に削除する予定です。
ファイルはでにリンクをpacificnew設定し、ファイルはでにリンクを設定します。したがって、理論的にはデータは正確でなければなりませんが、これはファイルに含まれる内容によって異なります。US/Pacific-NewAmerica/Los_AngelesbackwardUS/PacificAmerica/Los_AngelesLos_Angeles