私の雇用者はヨーロッパ（CET）にいるので、夏時間を使用しているので、年に2回1時間往復する必要があります。私たちのサーバーはさまざまな場所のクラウドで動作します。すべてのインフラを構築した従業員が消えた。彼はすべてのサーバー（現在、Ubuntu 18.04、20.04、22.04）でシステムタイムゾーンでUTCを使用することにしました。
年間の時間によっては、ログファイルに表示される各日付に精神的に1/2時間を追加する必要があるため、これは理想的ではありません（夏には+2時間、冬には+1時間）。一部のcronjobのタイミングは、ジョブがCET正午に実行される必要があるため、年に2回調整する必要があります。
（まだ）UTCをシステムタイムゾーンで使用するのに適した理由はありますか？それとも、cronjobとログファイルが壁時計とより整合するようにCETに切り替える必要がありますか？
答え1
（まだ）UTCをシステムタイムゾーンで使用するのに適した理由はありますか？
はい、そうです！ 2023年10月29日02:30に発生した主なイベントについて考えてみましょう。ログメッセージが正しく生成されました。 （この日付/時間の関連性は、ヨーロッパ全域の時計がその日の朝に1時間後に設定され、CEST/CETの場合、切り替え時間がその日の朝午前3時ということです。）
UTCを実行している場合、タイムスタンプは明確です*。 CEST/CETに変換する必要があるかもしれませんが、絶対時間は確かに知っています。一方、現地時間で走る場合は、02時から03時の間に、今回が最初か2番目かを最初に判断しなければなりません。ログメッセージの数によっては、これが不可能な場合があります。
クローン操作は問題になりましたが、推奨使用CRON_TZまたはタイマー単位での移行systemdもう一つの答えこの問題を賢く解決します。
*言及されているように、時々うるう秒を除いてアコスタディノフ
答え2
私はログを読むのが難しいことを本当に理解しています。しかし、米国とドイツの同僚とログファイルの時間について議論したくありません。毎年約2週間の夏時間は、ある大陸には影響し、他の大陸には影響しません。個人的には、これは間違いなくローカルで主に使用されるサービス（たとえば、プリントサーバー - アリゾナ州の誰かがドイツ南部の私のプリンターで印刷するのとは異なります）に関連していますが、メールサーバーログでUTC以外のものが見つかりました。タイムスタンプが混乱しています。
あなたのcron作業に関しては、私はゆっくりとシステムタイマーデバイスを好み、良いole crontabから抜け出そうとしています。彼らはOnCalendar=畑を持っていて、タイムゾーンの指定が必要です。！したがって、RFC 2324伝送はベルリンで午前7時に開始されると言えます。
はい、サーバーの場合はUTCを維持してください。しかし正直、私の考えでは一貫性ここには、「小麦が行政的美しさを考慮したもの」よりも多くあります。残りの管理範囲/隣接チームとユーザーがCETを期待している場合は、必ずCETを使用してください。すべてが機能するはずです。
便宜上：
1私は異常値である場合もある。私の機械式時計もUTCです。
答え3
サーバーは常にUTCを保存する必要があります。現地時間は、人間だけが見ることができるプレゼンテーション階層の問題です。ユーザーとしてタイムスタンプのあるデータを見たい場合は、サーバーがどのように考えているかにかかわらず、自分の時間帯に見たいと思うでしょう。
UTCはすべての人に明確であり（うるう日/秒を含む）、夏時間と重ならない（特別な状況を除く）。
現地時間は6ヶ月ごとに重複する可能性があるため、現地時間をタイムスタンプとして使用してログを見ると、3月にはその時間が欠落しているように見えますが、10月にはその時間があるように見えます。二重。
答え4
UTCの欠点がわかります（現地時間に精神的に変換するのは難しい）。 UTCの利点や問題を見ることはできません。すべてのサーバーに時間に同意することは非常に重要です。サーバーを現地時間に変更してみると、すぐにわかります。
サーバーをUTCに保ちます。ログを調べるのに役立ついくつかのツールを作成することを検討してください。たとえば、これらのツールは日付を現地時間で表示できます。または、時間に合わせてログを密接にグループ化します。あるいは、読み取れない32バイトIDを「id1」、「id2」などに置き換えて、同じタスクに属するログ行を知ることもできます。または、ほぼ同じログライン1000個を削除してください。