83

一般に、時間を UTC で保存することをお勧めします。

繰り返し発生するイベントがあるとします。これは、そのタイム ゾーンで夏時間がオンかオフかに関係なく、常に同じ現地時間 (たとえば 17:00 など) であるとします。また、特定のタイム ゾーンで DST がオンまたはオフになったときに時間を手動で変更しないという要件もあります。また、API (つまり GetEndTimeByEvent) を介して他のシステムから終了時刻が要求されるたびに、常に UTC 形式で終了時刻を送信することも要件です。

アプローチ 1: UTCで保存する ことにした場合は、以下のようにデータベース テーブルに保存できます。

Event      UTCEndTime
=====================
ABC         07:00:00
MNO         06:00:00
PQR         04:00:00

最初のイベント ABC の場合、UTC での終了時刻は午前 07:00 であり、2012 年 7 月 1 日に UTC から現地時間に変換して表示すると、現地時間の 17:00 になり、2012 年 10 月 10 日に変換すると (タイム ゾーンの DST がオンになっている日付) は、正しい終了時間ではない午後 6 時になります。

考えられる 1 つの方法は、追加の列に DST 時間を格納し、タイムゾーンで DST がオンになっているときにその時間を使用することです。

アプローチ 2: ただし、イベント ABC の例として以下のように現地時間として保存されている場合、UTC から現地時間への変換がないため、どの日付でも常に 17:00 になります。

Event      LocalEndTime
=======================
ABC         17:00:00
MNO         16:00:00
PQR         14:00:00

また、アプリケーション レイヤーはローカル時間を UTC 時間に変換し、(API GetEndTimeByEvent) を介して他のシステムに送信します。

この場合、時間を UTC で保存することをお勧めしますか? はいの場合、一定の現地時間を取得する方法は?

関連する質問: UTC 以外の時間を保存する正当な理由はありますか?

4

7 に答える 7

101

その質問に答えるには、UTC を使用してタイムスタンプを保存する利点について考える必要があると思います。

個人的には、その主な利点は、時間が常に (ほとんど)一貫性が保証されていることだと思います。つまり、タイムゾーンが変更されたり、DST が適用されたりすると、時間を前後に移動することはできません。これは、ファイルシステム、ログなどで特に役立ちます。しかし、それはあなたのアプリケーションで必要ですか?

2つのことを考えてください。まず、DSTのクロックシフトの時間について。イベントが午前 2 時から午前 3 時 (クロック シフトが行われる日) の間に発生する可能性はありますか? ではどうすればよいのでしょうか。

次に、アプリケーションは実際のタイムゾーンの変更の影響を受けますか? 言い換えれば、ロンドンからワルシャワまで飛行機で移動し、コンピューターのタイムゾーンを適切に変更しますか? その場合はどうすればよいですか？

これらの質問の両方に「いいえ」と答えた場合は、現地時間の方が適切です。それはあなたのアプリケーションをより簡単にします。しかし、少なくとも 1 回は「はい」と答えた場合は、もっと考えるべきだと思います。

そして、それはデータベースに関するすべてでした。もう 1 つは、アプリケーションによって内部的に使用される時間形式です。これは、その時間で実際に何をするかによって異なります。

APIを介して時間を公開すると述べました。アプリケーションはリクエストごとにデータベースにクエリを実行しますか? 時刻を UTC として内部に保存する場合は、それを行うか、DST/タイムゾーンの変更時にキャッシュされた時刻が調整/プルーニングされるようにする必要があります。

それは時間自体で何かをしますか？印刷のように、イベントは 8 時間後に発生しますか、それともその時間に中断されますか? もしそうなら、おそらくUTCの方が良いでしょう。もちろん、前述の問題をすべて考慮する必要があります。

于 2012-07-21T07:55:58.850 に答える
33

私はそれを次のように考えるのが好きです：

コンピューターは、人間が理解できる表現としての時間を気にしません。彼らは、タイムゾーン、日付と時刻の文字列のフォーマット、またはそのいずれも気にしません。時間をどのように解釈して表現するかを気にするのは人間だけです。

データベースに得意なことをさせてください: UNIX エポック (1970-01-01 から経過した秒数) または UTC タイムスタンプ (タイムゾーンまたは夏時間情報なし) のいずれかの数値として時間を格納します。必要な場合にのみ、人間が理解できる方法で時間を表現することに関心を持ってください。つまり、アプリケーション ロジック、レポート システム、コンソール アプリケーション、または人間がデータを表示するその他の場所で使用されます。

于 2013-12-19T16:51:57.693 に答える
9

以下は真のマルチテナント グローバル SaaS 製品には当てはまらないため、この意見は単純な「基幹業務」アプリ開発者を対象としています。

UTC として保存することは問題ありませんが、これを行うと面倒な要件が 1 つあります。

日付を UTC として保存する場合、この要件によって問題が発生します。アプリケーション サーバーとレポートにタイムゾーン調整コードを記述する必要があります。日付基準を含むデータに対して実行するアドホック クエリはすべて、これを考慮に入れる必要があります。

以下の条件を満たしたお申し込みの場合：

  1. 各インスタンスは、単一のタイムゾーンに基づいています。
  2. タイムゾーンの移行は通常、営業時間外に行われるか、時間の不足が問題になるレベルまでの「期間」をあまり気にしません。

サーバーのタイムゾーン構成の問題 (.net の世界では Noda.Time など) から分離するライブラリを使用しながら、日時をローカルの日時として保存することをお勧めします。

于 2016-04-10T04:55:56.833 に答える