有害と見なされるサーバーのローカルタイムゾーン？
リモート管理されたサーバーのコンテキストで、他の管理者のタイムゾーンの経験がどのようなものか知りたいです。私のキャリアの中で、私はいくつかの慣習に出くわしました。
- 常に、常に、常にUTCを使用します。
- 常に、常に、常にベースHQがある場所のタイムゾーンを使用します。
- たまたま管理している人の現地時間を使用してください。
- サーバーの場所の現地時間を使用します。
いくつかの場所で、私は複数の矛盾する慣習に出くわしました。私自身の好みは、常にUTCを使用することでしたが、夏時間はありません。しかし、何らかの理由で、ほとんどの人は夏時間のある現地時間の概念を使用することを好むようです。簡単な技術的な問題のように思えますが、慣習の変更に関する議論は常に宗教的分裂に向かう傾向があるようです。
何を使っていますか？それぞれのアプローチの長所と短所は何だと思いますか？
- ハードウェアクロックは常にUTCである必要があります。常に。
- 設定としてのタイムゾーンは、都合のよいものであれば何でもかまいません。通常。 UTCの場合もあります。
UTCが素晴らしい理由：
- 夏時間のルールは変更され、更新は常にタイムリーに行われるとは限りません。 UTCはこれをなくします。
- 異なる場所にあるサーバーからのログを比較する必要がある場合、UTCは非常に一般的な標準になります。
- 通常、サーバーが異なる場所にある場合、データベースの挿入などを実行する際に、人またはアプリケーション、あるいはその両方が時間変換を処理する必要があります。 （UTCへの）単一の変換がある場合は、サーバーTZによって異なりますが、あるTZから別のTZに変換する必要がある場合よりも、はるかに正しく取得するのが簡単です。
私はオプション4を好みます。サーバーで実行されているアプリケーションは、DateTime値をUTCで保存するかどうかを決定する責任があります。
また、サーバーがシステムイベントログを記録するときに、ローカルイベントをログエントリと関連付けることができるのは素晴らしいことです。たとえば、データセンターが現地時間でネットワークの中断を報告した場合、頭の中で時間の値を変換しなくても、発生した問題を簡単に特定できます。
いや、いや、千回もいや。
プログラマーには2つのタイプがあります...現地時間は表示/フォーマットの目的で使用する必要があることを理解している人のみと自分自身をコーナー...そして彼らは灯油でペイントしています。
すべてのイベントはUTCで記録する必要があり、結果はユーザーに表示するためにのみ現地時間に変換されます。いまいましいのはこれを怠った人たちであり、二重に忌まわしいのはタイムゾーン情報を破棄する形式で現地時間を使用している人たちです（私が見ているのはあなた、Oracle DBA）。
汚染チェックのように考えてください... timespecをlocaltimeに変換し、それをSTDOUTに出力しないことを行うと、プログラムは致命的なエラーで終了するだけでなく、ソースを削除して教える必要があります。あなたはレッスンです。
選択肢が与えられたとき、私はBIOSクロックをUTCに維持するのが好きですが、実際のサーバー時間は現地時間です。マルチタイムゾーンが存在しないため、統一されたログのタイムスタンプは、たとえば3Mの場合の問題ではありません。
私はすべてのサーバーをUTCで実行し、制御できるサーバーをできるだけ早く変換します。
これまでの唯一の例外はアスタリスクサーバーで、これは現地時間に残さなければなりませんでした。 UTCに変更すると、アスタリスクが完全に壊れます。 （1.6になっています。今年後半にアップグレードするときに、これが問題にならないことを願っています。）
私の会社では、今年まですべてのサーバーを1つのTZに配置していました。現在、3つの新しいタイムゾーンにサーバーがあります。すべてのサーバーはローカルタイムゾーンで実行されます。これは、特に3つのタイムゾーンにまたがって実行されているWebサイトを分散しているため、ログ分析に非常に役立ちます。
ただし、1つの特殊なケースでは、顧客TZにサーバーを残しました。アプリケーションは1日のほとんど稼働しているはずであり、メンテナンスタスクは通常「夜間」に実行されるように設定されています。最初は、サーバーをTZに設定しましたが、メンテナンスタスクは、私たちの最愛の「眠っているときに働く」顧客にとっては非常に遅くなりました...
UTCも非常に優れたオプションです。ログを見るときに常にローカルタイムゾーンを参照しない限り（ここではそうです）。