サーバー上のローカルタイムゾーンは有害と見なされますか？[閉まっている]

リモートで管理されているサーバーのコンテキストで、他の管理者がタイムゾーンをどのように経験しているかに興味があります。私のキャリアの中で、私はいくつかのコンベンションに出会いました。

1. 常に、常に、常にUTCを使用します。
2. 常に、常に、常にベースHQのタイムゾーンを使用します。
3. 管理している人の現地時間を使用します。
4. サーバーの場所の現地時間を使用します。

いくつかの場所で、私は複数の矛盾する慣例に遭遇しました。私自身の好みは、夏時間なしで常にUTCを使用することでした。しかし、何らかの理由で、ほとんどの人は夏時間のあるローカル時間の概念を使用することを好むようです。それは簡単な技術的な問題のように思えますが、変化する慣習に関する議論は常に宗教的分裂に向かっているようです。

何を使っていますか？各アプローチの長所と短所は何だと思いますか？

• ハードウェアクロックは常にUTCである必要があります。常に。
• 設定としてのタイムゾーンは、便利なものであれば何でもかまいません。通常。場合によってはUTCである必要もあります。

UTCが良い理由：

• 夏時間の規則が変更され、更新が常にタイムリーに行われるとは限りません。UTCはこれをなくします。
• 別の場所にあるサーバーからのログを比較する必要がある場合、UTCは非常に一般的な標準になります。
• 通常、サーバーが異なる場所にある場合、人またはアプリケーション、あるいはその両方が、データベースの挿入などの実行中に時間変換を処理する必要があります。単一の変換（UTCへの変換）がある場合、サーバー、TZによって異なるTZから別のTZに変換する必要がある場合よりも、正しく取得する方がはるかに簡単です。

オプション4をお勧めします。UTCでDateTime値を保存するかどうかを決定するのは、サーバーで実行されているアプリケーションの責任です。

また、サーバーがシステムイベントログを記録するとき、ローカルイベントをログエントリと関連付けることができると便利です。たとえば、データセンターが現地時間でネットワークの中断を報告した場合、頭の中で時間値を変換することなく、発生した問題を簡単に特定できます。

いや、いや、千回もいや。

プログラマーには2つのタイプがあります...現地時間は表示/フォーマットの目的にのみ使用する必要があることを理解している人と、隅に自分自身をペイントしている人...そして彼らは灯油でペイントしています。

すべてのイベントはUTCで記録され、結果はユーザーに表示するためにのみ現地時間に変換されます。これに失敗した人はひどく、タイムゾーン情報を破棄する形式で現地時間を使用している人は二重にひどい人です（私はあなた、Oracle DBAを見ています）。

それを汚染チェックのように考えてください... timespecをlocaltimeに変換し、それをSTDOUTに出力しないものを使用すると、プログラムは致命的なエラーで終了するだけでなく、ソースを削除して教える必要がありますあなたのレッスン。

選択肢が与えられたら、UTCのBIOSクロックを維持しますが、実際のサーバー時間は現地時間として維持します。複数のタイムゾーンが存在するわけではないため、統合ログのタイムスタンプは、たとえば3Mの場合の問題ではありません。

私の会社では、今年まで単一のTZにすべてのサーバーがありました。現在、3つの新しいタイムゾーンにサーバーがあります。すべてのサーバーはローカルタイムゾーンで実行されます。これは、特に3つのタイムゾーンで実行されているWebサイトを分散しているため、ログ分析に非常に役立ちます。

ただし、1つの特別なケースでは、顧客TZにサーバーを残しています。アプリケーションはほとんどの時間、稼働しているはずであり、通常、メンテナンスタスクは「夜」に実行するようにセットアップされます。最初は、サーバーをTZに設定しましたが、保守タスクは、最愛の「眠っているときは仕事をしている」顧客にとっては非常に遅くなりました...

UTCも非常に便利なオプションです。ログを見るときに人々が常にローカルのタイムゾーンを参照している場合を除きます（ここでのケースです）。

すべてのサーバーをUTCで実行し、できる限り早く制御するサーバーを変換します。

これまでの1つの例外は、アスタリスクサーバーでした。これは現地時間に残す必要がありました。UTCに変更すると、アスタリスクが完全に壊れました。（それは1.6にあります。願わくば、今年後半にアップグレードする際にこれが問題にならないことを願っています。）