この質問とその回答が、夏時間を処理するための、特に実際の変更を処理するための決定的なガイドになることを願っています。

追加するものがあれば、どうぞ

多くのシステムは正確な時刻を維持することに依存しています。問題は、夏時間による時刻の変更-時計を前後に動かすことです。

たとえば、注文受付システムには、注文の時間に依存するビジネスルールがあります。時計が変わった場合、ルールはそれほど明確ではない可能性があります。注文の時間をどのように維持する必要がありますか？もちろん、シナリオは無数にあります-これは単なる説明のためのものです。

• 夏時間の問題にどのように対処しましたか？
• ソリューションにはどのような前提条件がありますか？（ここでコンテキストを探します）

それほど重要ではないにしても、重要です：

• うまくいかなかったのに何を試しましたか？
• なぜうまくいかなかったのですか？

プログラミング、OS、データの永続化、および問題の他の関連する側面に興味があります。

一般的な回答はすばらしいですが、特に1つのプラットフォームでしか利用できない場合は、詳細も確認してください。

回答とその他のデータの要約：（あなたのものを追加してください）

行う：

• 正確な時刻を参照する場合は常に、夏時間の影響を受けない統一規格に従って時刻を維持してください。（この点ではGMTとUTCは同等ですが、UTCという用語を使用することをお勧めします。UTCはズールー語またはZ時間としても知られていることに注意してください。）
• 代わりにローカル時刻値を使用して時刻を保持することを選択した場合は、UTCからのこの特定の時刻のローカル時刻オフセットを含めます（このオフセットは1年を通して変化する可能性があります）。これにより、後でタイムスタンプを明確に解釈できます。
• 場合によっては、UTC時間とそれに相当する現地時間の両方を保存する必要があります。多くの場合、これは2つの別々のフィールドで行われますが、一部のプラットフォームdatetimeoffsetでは、両方を1つのフィールドに格納できるタイプがサポートされています。
• タイムスタンプを数値として保存する場合は、Unix時間を使用します。これは、1970-01-01T00:00:00Zうるう秒を除いてからの秒数です。より高い精度が必要な場合は、代わりにミリ秒を使用してください。この値は、タイムゾーンの調整なしで、常にUTCに基づく必要があります。
• 後でタイムスタンプを変更する必要がある場合は、元のタイムゾーンIDを含めて、オフセットが記録された元の値から変更されたかどうかを判断できるようにします。
• 将来のイベントをスケジュールするときは、オフセットが変更されるのが一般的であるため、通常はUTCではなく現地時間が推奨されます。 回答とブログ投稿を参照してください。
• 誕生日や記念日などの日付全体を保存する場合は、UTCまたはその他のタイムゾーンに変換しないでください。
  • 可能であれば、時刻を含まない日付のみのデータ型で保存します。
  • そのようなタイプが使用できない場合は、値を解釈するときに常に時刻を無視するようにしてください。時刻が無視されることが保証できない場合は、その日のより安全な代表時刻として、深夜00:00ではなく正午12:00を選択します。
• タイムゾーンのオフセットは常に整数の時間数ではないことに注意してください（たとえば、インド標準時はUTC + 05：30であり、ネパールではUTC + 05：45を使用しています）。
• Javaを使用する場合は、Java 8以降の場合はjava.timeを使用します。
  • そのjava.time機能の多くは、ThreeTen-BackportライブラリのJava 6および7にバックポートされています。
  • ThreeTenABPライブラリで初期のAndroid（<26）にさらに適合。
  • これらのプロジェクトは、由緒あるJoda-Timeに代わって、現在はメンテナンスモードになっています。Joda-Time、ThreeTen-Backport、ThreeTen-Extra、java.timeクラス、およびJSR 310は、同じ人物、Stephen Colebourneが率いています。
• .NETを使用している場合は、野田時間の使用を検討してください。
• Noda Timeを使用せずに.NETを使用する場合DateTimeOffsetは、多くの場合、それよりも適切であると考えてDateTimeください。
• Perlを使用している場合は、DateTimeを使用します。
• Pythonを使用している場合は、pytzまたはdateutilを使用してください。
• JavaScriptを使用している場合は、moment-timezone拡張機能付きのmoment.jsを使用します。
• PHP> 5.2を使用している場合はDateTime、およびDateTimeZoneクラスによって提供されるネイティブのタイムゾーン変換を使用します。使用するときは注意してくださいDateTimeZone::listAbbreviations() - 回答を参照してください。PHPを最新のOlsonデータで維持するには、timezonedb PECLパッケージを定期的にインストールします。回答を参照してください。
• C ++を使用している場合は、IANAタイムゾーンデータベースを適切に実装したライブラリを使用してください。これらには、cctz、ICU、およびハワードヒンナンの「tz」ライブラリが含まれます。
  • タイムゾーンの変換にBoostを使用しないでください。一方でそのAPIのクレームは標準IANA（「zoneinfoの」別名）識別子をサポートするために、それはぞんざいにそれらをマッピングし、各ゾーンが持っていたかもしれない変化の豊かな歴史を考慮せず、POSIXスタイルのデータに。（また、ファイルはメンテナンスから外れています。）
• Rustを使用している場合は、chronoを使用します。
• ほとんどのビジネスルールは、UTCまたはGMTではなく、常用時を使用します。したがって、アプリケーションロジックを適用する前に、UTCタイムスタンプをローカルタイムゾーンに変換することを計画してください。
• タイムゾーンとオフセットは固定されておらず、変更される可能性があることに注意してください。たとえば、歴史的に、米国と英国は同じ日付を使用して、「春先」と「後退」に使用しました。ただし、2007年に米国は時計が変更される日付を変更しました。これは、1年のうち48週間のロンドン時間とニューヨーク時間の差が5時間であり、4週間（春に3、秋に1）の場合、4時間であることを意味します。複数のゾーンが関係する計算では、このような項目に注意してください。
• 時間のタイプ（実際のイベント時間、ブロードキャスト時間、相対時間、履歴時間、繰り返し時間）を考慮して、正しい検索のために格納する必要のある要素（タイムスタンプ、タイムゾーンオフセット、タイムゾーン名）を検討します。「時間のタイプ」を参照してください。この答え。
• OS、データベース、アプリケーションのtzdataファイルを、それらと他の世界との間で同期させます。
• サーバーでは、ハードウェアクロックとOSクロックをローカルタイムゾーンではなくUTCに設定します。
• 前の箇条書きに関係なく、 Webサイトを含むサーバー側のコードは、サーバーのローカルタイムゾーンが特定のものであることを期待するべきではありません。 回答を参照してください。
• 構成ファイルの設定やデフォルトを介してグローバルに設定するのではなく、アプリケーションコードでケースバイケースでタイムゾーンを操作することをお勧めします。
• すべてのサーバーでNTPサービスを使用します。
• FAT32を使用する場合、タイムスタンプはUTCではなく現地時間で保存されることに注意してください。
• 定期的なイベント（たとえば、毎週のテレビ番組）を処理する場合、時刻はDSTによって変化し、タイムゾーンによって異なることに注意してください。
• 日時値は常に下限値を含む上限値、上限値を含まない（>=、<）としてクエリします。

してはいけないこと：

• などAmerica/New_Yorkの「タイムゾーンオフセット」などの「タイムゾーン」を混同しないでください-05:00。彼らは2つの異なるものです。タイムゾーンタグwikiをご覧ください。
• DateECMAScript 5.1以前には、夏時間を誤って使用する可能性がある設計上の欠陥があるため、 JavaScriptのオブジェクトを使用して古いWebブラウザーで日付と時刻の計算を実行しないでください。（これはECMAScript 6/2015で修正されました）。
• クライアントの時計を信用しないでください。間違いかもしれません。
• 「常にどこでもUTCを使用する」ように人々に言わないでください。この広範なアドバイスは、このドキュメントの前半で説明されているいくつかの有効なシナリオの近視眼的です。代わりに、使用しているデータに適切な時間参照を使用してください。（タイムスタンプはUTCを使用できますが、将来のタイムスケジューリングと日付のみの値は使用しないでください。）

テスト：

• テストする場合は、西、東、北とで必ずテスト国を作る南（SO 4つの地域、世界の各四半期に実際に）半球、DST進行中とではない（8を与える）、および国の両方でないことDSTを使用しないでください（すべての地域をカバーするために別の4、合計12を作成）。
• DSTの移行をテストします。つまり、現在夏時間である場合は、冬から時間値を選択します。
• UTC + 12のタイムゾーンなどの境界ケースをDSTでテストし、現地時間を夏はUTC + 13、冬はUTC + 13の場所を作成する
• すべてのサードパーティのライブラリとアプリケーションをテストし、タイムゾーンデータを正しく処理することを確認します。
• 少なくとも30分タイムゾーンをテストします。

参照：

• timezoneStack Overflow の詳細なタグwikiページ
• Olsonデータベース、別名Tz_database
• Olsonデータベースを維持するためのIETFドラフト手順
• タイムゾーンとDSTのソース
• ISOフォーマット（ISO 8601）
• UnicodeコンソーシアムのOlsonデータベースとWindowsタイムゾーンID間のマッピング
• ウィキペディアのタイムゾーンページ
• タグ付けされたStackOverflowの質問 dst
• タグ付けされたStackOverflowの質問 timezone
• DSTの扱い-Microsoft DateTimeのベストプラクティス
• ウィキペディアのネットワークタイムプロトコル

その他：

• DSTである嫌悪感を終わらせるために、あなたの代表者に働きかけます。私たちはいつも願っています...
• 地球標準時のロビー

上記の回答に何を追加できるかわかりませんが、ここにいくつかのポイントがあります。

時間の種類

考慮すべき4つの異なる時間があります。

1. イベント時間：たとえば、国際的なスポーツイベントが発生した時間、戴冠式/死/など。これは、ビューアではなくイベントのタイムゾーンに依存します。
2. テレビ時間：たとえば、特定のテレビ番組は、世界中の現地時間午後9時に放送されます。ウェブサイトに（たとえばアメリカンアイドルの）結果を公開することを考えるときに重要
3. 相対時間：例：この質問には、21時間で終了する報奨金があります。これは表示が簡単です
4. 定期的な時間：例：DSTが変更された場合でも、テレビ番組は毎週月曜日の午後9時に行われます。

歴史的/交互の時間もあります。これらは標準時間にマッピングできない可能性があるため、迷惑です。例：ユリウス暦、土星の旧暦、クリンゴン暦による日付。

開始/終了のタイムスタンプをUTCに保存するとうまくいきます。1の場合、イベントと共に保存されるイベントのタイムゾーン名+オフセットが必要です。2の場合、各地域に保存されたローカル時間識別子と、すべてのビューアに保存されたローカルタイムゾーン名+オフセットが必要です（緊張している場合は、IPからこれを取得することができます）。3の場合、UTC秒で保存し、タイムゾーンは必要ありません。4は、グローバルイベントかローカルイベントかによって、1または2の特殊なケースですが、タイムゾーンの定義がこのイベントの作成前または後に変更されたかどうかを確認できるように、作成時にタイムスタンプを保存する必要もあります。これは、履歴データを表示する必要がある場合に必要です。

保管時間

• 時間は常にUTCで保存する
• ディスプレイの現地時間に変換します（現地時間は、データを見ているユーザーによって定義されます）
• タイムゾーンを保存するときは、名前、タイムスタンプ、オフセットが必要です。これは、政府がタイムゾーンの意味を変更する場合があるため（たとえば、米国政府がDSTの日付を変更したため）、アプリケーションで適切に処理する必要があるため、これが必要です。かわった。

オフセットと名前

上記の例は次のとおりです。

サッカーワールドカップの決勝戦は、2010年7月11日19:00 UTCに南アフリカ（UTC + 2--SAST）で開催されました。

この情報を使用して、我々は歴史的に2010 WCS決勝戦でも南アフリカのタイムゾーンの定義が変更された場合に行われた、正確な時刻を決定することができますし、彼らはデータベースを照会時に自分のローカルのタイムゾーンで視聴者にあることを表示することができます。

システム時刻

また、OS、データベース、アプリケーションのtzdataファイルを相互に、また他の世界と同期させ、アップグレード時に広範囲にテストする必要があります。あなたが依存しているサードパーティのアプリがTZの変更を正しく処理しなかったことは前代未聞ではありません。

ハードウェアクロックがUTCに設定されていることを確認します。世界中でサーバーを実行している場合は、それらのOSもUTCを使用するように構成されていることを確認してください。これは、複数のタイムゾーンのサーバーから1時間ごとにローテーションされるapacheログファイルをコピーする必要がある場合に明らかになります。ファイル名での並べ替えは、すべてのファイルの名前が同じタイムゾーンである場合にのみ機能します。また、あるボックスから別のボックスにsshしてタイムスタンプを比較する必要がある場合、頭の中で日付の計算を行う必要がないことも意味します。

また、すべてのボックスでntpdを実行します。

クライアント

クライアントマシンから取得したタイムスタンプを有効なものとして信頼しないでください。たとえば、Date：HTTPヘッダーやJavaScript Date.getTime()呼び出しなどです。これらは、不透明な識別子として使用する場合、または同じクライアントで単一のセッション中に日付の計算を行う場合は問題ありませんが、これらの値をサーバー上にあるものと相互参照しないでください。クライアントはNTPを実行していないため、必ずしもBIOSクロック用のバッテリーが動作しているとは限りません。

トリビア

最後に、政府は時々非常に奇妙なことをします：

オランダの標準時は、法律により1909-05-01から1937-06-30までUTCより19分32.13秒進んでいました。このタイムゾーンは、HH：MM形式を使用して正確に表すことはできません。

了解しました。

これは重要で驚くほど難しい問題です。真実は、時間を持続させるための完全に満足できる基準はないということです。たとえば、SQL標準とISO形式（ISO 8601）では明らかに不十分です。

概念的な観点から見ると、通常は2種類の日時データを扱い、それらを区別するのが便利です（上記の標準では区別されません）。「物理時間」と「常用時間」です。

「物理的」な瞬間とは、物理学が扱う連続的な普遍的なタイムラインのポイントです（もちろん、相対性理論は無視します）。この概念は、たとえばUTCで適切にコード化して永続化できます（うるう秒を無視できる場合）。

「シビル」タイムは、シビルノルムに従う日時指定です。ここでのポイントは、一連の日時フィールド（Y、M、D、H、MM、S、FS）とTZ（タイムゾーン指定）によって完全に指定されます。 （実際には「カレンダー」でもありますが、議論をグレゴリオ暦に限定するとします）。タイムゾーンとカレンダーにより、（原則として）1つの表現から別の表現へのマッピングが可能になります。しかし、民生と物理の時刻は基本的に大きさの種類が異なるため、概念的に分離し、異なる方法で処理する必要があります（類推：バイトと文字列の配列）。

私たちはこれらのタイプのイベントについて交換可能に話しているため、そして市民時代は政治的変化の影響を受けやすいため、問題は混乱しています。問題（およびこれらの概念を区別する必要性）は、将来のイベントでさらに明らかになります。例（私の議論から取らここに。

ジョンは、カレンダーに日付時刻2019-Jul-27, 10:30:00TZ =の何らかのイベントのリマインダーを記録します Chile/Santiago（GMT-4のオフセットがあるため、UTCに対応します2019-Jul-27 14:30:00）。しかし、将来的には、国はTZオフセットをGMT-5に変更することを決定します。

さて、その日が来たら...そのリマインダーが

A）2019-Jul-27 10:30:00 Chile/Santiago = UTC time 2019-Jul-27 15:30:00？

または

B）2019-Jul-27 9:30:00 Chile/Santiago = UTC time 2019-Jul-27 14:30:00？

ジョンがカレンダーに「私に電話してください」と言ったときに概念的に何を意味しているかを知らない限り、正しい答えはありません2019-Jul-27, 10:30:00 TZ=Chile/Santiago。

彼は「市民の日付時刻」（「私の街の時計が10:30を告げる時」）を意味しましたか？その場合、A）が正解です。

それとも彼は「物理的な瞬間」、つまり私たちの宇宙の連続線のポイントの意味で、「次の日食がいつ起こるか」と言ったのでしょうか。その場合、B）が正解です。

いくつかの日付/時刻APIはこの区別を正しくしています。その中には、次の（3番目の）Java DateTime API（JSR 310）の基礎であるJodatimeがあります。

アーキテクチャを明確に分離して、どの層がユーザーと対話するかを正確に把握し、正規表現（UTC）の日時を変更する必要があります。非UTC日時はプレゼンテーションであり（ユーザーのローカルタイムゾーンに従います）、UTC時間はモデルです（バックエンド層と中間層で一意のままです）。

また、実際の視聴者、配信する必要がないもの、どこに線を引くかを決定します。重要な顧客が実際にいる場合を除いて、エキゾチックなカレンダーに触れないでください。その地域専用のユーザー向けサーバーを個別に検討してください。

ユーザーの場所を取得して維持できる場合は、体系的な日時変換（たとえば、.NETカルチャまたはSQLテーブル）に場所を使用しますが、ユーザーにとって日時が重要な場合は、エンドユーザーがオーバーライドを選択する方法を提供します。

履歴監査の義務がある場合（AZのJoが2年前に9月に請求書をいつ支払ったかを正確に伝えるなど）、UTCと現地時間の両方を記録に残します（変換テーブルは時間の経過とともに変化します）。

ファイル、Webサービスなど、大量に送信されるデータの時間参照タイムゾーンを定義します。たとえば、東海岸の会社にはCAにデータセンターがあります。どちらか一方を想定するのではなく、標準として何を使用するかを尋ねて知る必要があります。

日時のテキスト表現に埋め込まれたタイムゾーンオフセットを信頼せず、それらの解析と追跡を受け入れないでください。代わりに、タイムゾーンや参照ゾーンを明示的に定義する必要があることを常に要求してください。PSTオフセットで時間を簡単に受け取ることができますが、それはクライアントの参照時間であり、レコードはPSTにあるサーバーでエクスポートされただけなので、実際にはESTです。

ftp://elsie.nci.nih.gov/pubから入手できるOlson tzデータベースについて知っておく必要があります。 http://iana.org/time-zones/。世界中のさまざまな国で冬時間と夏時間（標準時間と夏時間）を切り替える時期（および時期）の頻繁な最後の変更に対処するために、年に数回更新されます。2009年の最後のリリースは2009年代でした。2010年には2010nでした。2011年は2011nでした。2012年5月末のリリースは2012cでした。2つの別々のアーカイブ（tzcode20xxy.tar.gzとtzdata20xxy.tar.gz）に、データと実際のタイムゾーンデータ自体を管理する一連のコードがあることに注意してください。コードとデータの両方がパブリックドメインにあります。

これは、America / Los_Angeles（およびUS / Pacificなどの同義語）などのタイムゾーン名のソースです。

さまざまなゾーンを追跡する必要がある場合は、Olsonデータベースが必要です。他の人がアドバイスしているように、データを固定形式で保存することもできます—通常はUTCが選択されます-データが生成されたタイムゾーンのレコードと共に。そのときのUTCからのオフセットとタイムゾーン名を区別したい場合があります。それは後で違いを生むことができます。また、それが現在2010-03-28T23：47：00-07：00（米国/太平洋）であることを知っていると、おそらく2010-11-15T12：30の解釈に役立つ場合とそうでない場合があります。これはおそらくPST（ PDT（太平洋夏時間）ではなく、太平洋標準時）。

標準のCライブラリインターフェイスは、この種のものではひどく役に立ちません。

オルソンのデータは、ADオルソンが間もなく廃止されることと、著作権侵害に対するメンテナに対する（現在は却下された）訴訟があったことの理由の1つで移動しました。現在、タイムゾーンデータベースはIANA（Internet Assigned Numbers Authority）の管理下で管理されており、フロントページに「タイムゾーンデータベース」へのリンクがあります。ディスカッションのメーリングリストは現在tz@iana.orgです。お知らせリストはtz-announce@iana.orgです。

一般に、現地時間のオフセット（DSTオフセットを含む）を含めます保存されているタイムスタンプにます。後でタイムスタンプを元のタイムゾーン（およびDST設定）で表示する場合は、UTCだけでは不十分です。

オフセットは常に整数の時間数ではないことに注意してください（たとえば、インド標準時はUTC + 05：30）。

たとえば、適切な形式はタプル（UNIX時間、分単位のオフセット）またはISO 8601です。

「コンピュータの時間」と「人の時間」の境界を越えることは悪夢です。主なものは、タイムゾーンと夏時間を管理するルールには、なんらかの標準がないということです。国はタイムゾーンとDSTルールをいつでも自由に変更できます。

一部の国（イスラエル、ブラジルなど）では、夏時間をいつ設定するかを毎年決定するため、DSTがいつ（いつ）有効になるかを事前に知ることはできません。他には、DSTが有効になる時期についてのルールが固定されています。他の国では、DSTをまったく使用していません。

タイムゾーンは、GMTとの時差である必要はありません。ネパールは+5.45です。+13のタイムゾーンさえあります。つまり、

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

すべて同じ時間ですが、3日間です！

また、タイムゾーンの省略形、およびDSTでそれらがどのように変更されるかについて明確な基準がないため、次のような結果になります。

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

最善のアドバイスは、できるだけ現地時間から離れて、可能な限りUTCを守ることです。可能な限り最後の時間にのみ現地時間に変換します。

テストを行うときは、西半球と東半球の国をテストし、DSTが進行中かどうか、およびDSTを使用していない国（合計6つ）をテストしてください。

PHPの場合：

PHP> 5.2のDateTimeZoneクラスはすでに他の人が言及しているOlson DBに基づいているため、DBではなくPHPでタイムゾーン変換を行っている場合、（理解しにくい）Olsonファイルでの作業は免除されます。

ただし、PHPはOlson DBほど頻繁には更新されないため、PHPのタイムゾーン変換を使用するだけで古いDST情報が残り、データの正確さに影響を与える可能性があります。これは頻繁に発生するとは予想されていませんが、発生する可能性があり、世界中に多数のユーザーがいる場合に発生します。

上記の問題に対処するには、timezonedb peclパッケージを使用します。その機能は、PHPのタイムゾーンデータを更新することです。このパッケージは、更新された頻度でインストールしてください。（このパッケージの更新がOlsonの更新に正確に従っているかどうかはわかりませんが、少なくともOlsonの更新の頻度に非常に近い頻度で更新されているようです。）

設計で対応できる場合は、現地時間の変換をすべて避けてください。

私はこれは狂ったように聞こえるかもしれませんが、UXについて考えます：ユーザーは一目で絶対日付（2010.09.17、9月17日金曜日）よりも相対的に近い日付（今日、昨日、次の月曜日）を処理します。さらに考えると、タイムゾーン（およびDST）の精度は、日付が近いほど重要now()です。そのため、+ /-1週間または2週間の相対形式で日付/日付時刻を表すことができれば、残りの日付はUTCにすることができ、95％のユーザーにとってはあまり重要ではありません。

このようにして、すべての日付をUTCで保存し、UTCで相対比較を行い、ユーザーのUTC日付を相対日付しきい値の外に表示することができます。

これはユーザー入力にも適用できます（ただし、一般的にはより限定的な方法で）。{昨日、今日、明日、次の月曜日、次の木曜日}しかないドロップダウンから選択することは、日付の選択よりもユーザーにとって非常に単純で簡単です。日付ピッカーは、フォーム入力の最も痛みを引き起こすコンポーネントの一部です。もちろん、これはすべてのケースで機能するわけではありませんが、非常に強力にするために少し巧妙な設計が必要なだけであることがわかります。

試したことはありませんが、タイムゾーンの調整を行うには、次のような方法があります。

1. すべてをUTCに保存します。

2. TZOffsetsRegionClassId、StartDateTime、OffsetMinutes（int、分単位）の3つの列を持つテーブルを作成します。

テーブルに、現地時間が変更された日付と時刻のリストを、どれだけ変更したかを格納します。テーブル内の地域の数と日付の数は、サポートする必要のある日付の範囲と世界の地域によって異なります。日付には実際的な限界まで未来が含まれているはずですが、これは「歴史的な」日付であるかのように考えてください。

UTC時間の現地時間を計算する必要がある場合は、次のようにします。

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

このテーブルをアプリにキャッシュし、LINQまたは同様の手段を使用して、データベースにアクセスするのではなくクエリを実行することができます。

このデータは、パブリックドメインのtzデータベースから抽出できます。

このアプローチの利点と脚注：

1. ルールはコードに組み込まれていません。新しい地域または日付範囲のオフセットを簡単に調整できます。
2. 日付や地域のすべての範囲をサポートする必要はなく、必要に応じてそれらを追加できます。
3. 地域は地政学的境界に直接対応する必要はなく、行の重複を回避するために（たとえば、米国のほとんどの州はDSTを同じように処理します）、別のテーブルでより伝統的なリストにリンクする広範なRegionClassエントリを持つことができます州、国など
4. 米国のようなDSTの開始日と終了日が過去数年間で変更された状況では、これは非常に簡単に対処できます。
5. StartDateTimeフィールドには時刻も格納できるため、午前2時の標準の切り替え時刻は簡単に処理されます。
6. 世界中で1時間のDSTが使用されているわけではありません。これはそれらのケースを簡単に処理します。
7. データテーブルはクロスプラットフォームであり、ほぼすべてのデータベースプラットフォームまたはプログラミング言語を使用する開発者が使用できる個別のオープンソースプロジェクトになる可能性があります。
8. これは、タイムゾーンとは関係のないオフセットに使用できます。たとえば、地球の回転を調整するために時々発生する1秒の調整、グレゴリオ暦への、およびグレゴリオ暦内での過去の調整など。
9. これはデータベーステーブルにあるため、標準のレポートクエリなどは、ビジネスロジックコードを介することなくデータを利用できます。
10. これは、必要に応じてタイムゾーンオフセットも処理し、地域が別のタイムゾーンに割り当てられている特別な履歴ケースを考慮に入れることもできます。必要なのは、最小の開始日で各地域にタイムゾーンオフセットを割り当てる最初の日付です。これには、タイムゾーンごとに少なくとも1つの地域を作成する必要がありますが、「1989年2月2日午前5時のアリゾナ州ユマとワシントン州シアトルの現地時間の違いは何ですか？」などの興味深い質問をすることができます。（一方から他方のSUM（）を引くだけです）。

現在、このアプローチまたはその他の唯一の欠点は、現地時間からGMT への変換が完全ではないことです。これは、クロックに対して負のオフセットを持つDSTの変更が、指定された現地時間を繰り返すためです。これに対処する簡単な方法はないと思います。ローカル時刻を格納することは、そもそも悪いニュースの1つの理由です。

私は最近、Ajaxポストバックでサーバー側のコードに戻る日時が、提供される日時と異なるWebアプリケーションで問題が発生しました。

JavaScriptはタイムゾーンと夏時間を調整しており、一部のブラウザーでは夏時間を適用するタイミングの計算を行っていたため、クライアントのJavaScriptコードを文字列としてクライアントにポストバックするための日付を作成した可能性があります。他のものとは違うように見えました。

最後に、クライアントでの日付と時刻の計算を完全に削除することを選択し、整数キーでサーバーにポストバックして、サーバーで日付時刻に変換して、一貫した変換を可能にしました。

これからの私の学び：絶対に必要でない限り、WebアプリケーションでJavaScriptの日付と時刻の計算を使用しないでください。

私はこれを「シフト計画システム（例：工場労働者）」と「ガス依存管理システム」の2種類のシステムに当てました…

23時間と25時間の長い日は対処するのが面倒なので、7時間または9時間かかる8時間シフトもそうです。問題は、顧客ごと、または顧客の部門でさえ、これらの特殊なケースで何をするかについて作成した（多くの場合、文書化されていない）異なるルールがあることに気付くでしょう。

「既製」のソフトウェアの支払いが済むまで、いくつかの質問は顧客に尋ねない方がよいでしょう。ソフトウェアを購入するときに、この種の問題を前もって考える顧客を見つけることは非常にまれです。

すべての場合において、UTCで時刻を記録し、日付/時刻を保存する前に現地時間に変換する必要があると思います。ただし、夏時間とタイムゾーンでは、特定の時間がどの時間にあるかを知ることさえ難しい場合があります。

ウェブの場合、ルールはそれほど複雑ではありません...

• サーバー側、UTCを使用
• クライアント側、Olsonを使用
  • 理由：UTCオフセットは夏時間に対して安全ではありません（たとえば、ニューヨークは年の一部でEST（UTC-5時間）、年の残りはEDT（UTC-4時間）です）。
  • クライアント側のタイムゾーンの決定には、2つのオプションがあります。
    • 1）ユーザーにゾーンを設定させる（より安全）
      • リソース：Web対応のOlson tz HTMLドロップダウンとJSON
    • 2）自動検出ゾーン
      • リソース：jsTimezoneDetect

残りは、サーバー側の日時ライブラリを使用したUTC /ローカル変換です。行ってもいい...

上で実行されるアプリケーションに関しては Webサイトやその他のバックエンドサービスなどサーバーサーバーのタイムゾーン設定を無視する必要があります。

一般的なアドバイスは、サーバーのタイムゾーンをUTCに設定することです。これは確かに良いベストプラクティスですが、他のベストプラクティスに従わないアプリケーションの応急処置として存在します。たとえば、サービスがUTCベースのタイムスタンプではなくローカルのタイムスタンプを使用してログファイルに書き込みを行っているため、夏時間のフォールバックの移行中にあいまいさが生じる場合があります。サーバーのタイムゾーンをUTCに設定すると修正されますと、そのアプリケーションれます。ただし、実際の修正は、アプリケーションが最初にUTCを使用してログを記録することです。

Webサイトを含むサーバー側のコードは、 は、サーバーのローカルタイムゾーンが特定のものであることを想定してません。

一部の言語では、ローカルタイムゾーンがアプリケーションコードに簡単に侵入できます。たとえばDateTime.ToUniversalTime、.NET のメソッドはローカルタイムゾーンからUTCに変換し、DateTime.Nowプロパティはローカルタイムゾーンの現在の時刻を返します。また、DateJavaScript のコンストラクターはコンピューターのローカルタイムゾーンを使用します。このような他の多くの例があります。コンピュータのローカルタイムゾーン設定を使用するコードを回避して、防御的プログラミングを実践することが重要です。

デスクトップアプリケーション、モバイルアプリケーション、クライアントサイドJavaScriptなどのクライアントサイドコード用にローカルタイムゾーンを使用して予約します。

サーバーをUTCに設定したままにし、すべてのサーバーがntpまたは同等のものに構成されていることを確認します。

UTCは夏時間の問題を回避し、非同期サーバーは予測できない結果を引き起こし、診断に時間がかかることがあります。

FAT32ファイルシステムに保存されているタイムスタンプを処理するときは注意してください-これは常にローカル時間座標で永続化されます（DSTを含む-msdnの記事を参照）。その上で焦げた。

もう1つ、サーバーに最新の夏時間パッチが適用されていることを確認してください。

昨年は、UTCベースのシステムを使用していても、北米のユーザーの場合、3週間、一貫して1時間ずれた状況がありました。

最終的にはサーバーでした。最新のパッチを適用する必要がありました（Windows Server 2003）。

PHPのDateTimeZone::listAbbreviations()出力

このPHPメソッドは、いくつかの「主要な」タイムゾーン（CESTなど）を含む連想配列を返します。これらには、独自の「地理的」タイムゾーン（ヨーロッパ/アムステルダムなど）が含まれています。

これらのタイムゾーンとそのオフセット/ DST情報を使用している場合は、次のことを理解することが非常に重要です。

ように思えるすべての異なるオフセット/ DSTの設定各タイムゾーンの（歴史的な構成を含む）が含まれています！

たとえば、ヨーロッパ/アムステルダムは、この関数の出力で6回見つかります。2つの発生（オフセット1172/4772）は、1937年まで使用されたアムステルダム時間です。2つ（1200/4800）は、1937年から1940年の間に使用された期間用です。そして2つ（3600/4800）は1940年以来使用された時間用です。

したがって、この関数によって返されるオフセット/ DST情報は、現在正しい/使用中であるとは言えません。

特定のタイムゾーンの現在のオフセット/ DSTを知りたい場合は、次のようにする必要があります。

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

DSTがアクティブな状態で実行されているデータベースシステムを保守している場合は、秋の移行中にシャットダウンする必要があるかどうかを慎重に確認してください。Mandy DBS（または他のシステム）は、同じ時刻を（ローカル）時間で2回渡すのが好きではありません。これは、秋に時計を戻すと正確に起こることです。SAPはこれを（IMHOは本当にきちんとした）回避策で解決しました-時計を戻すのではなく、内部時計を通常の半分の速度で2時間動作させます...

.NETフレームワークを使用していますか？その場合は、.NET 3.5で追加されたDateTimeOffsetタイプを紹介します。

この構造は、a DateTimeとオフセット（TimeSpan）の両方を保持します。これは、DateTimeOffsetインスタンスの日付と時刻と協定世界時（UTC）との差を指定します。

• DateTimeOffset.Now静的メソッドは戻りますDateTimeOffset 、現在の（ローカル）時間、及び（オペレーティングシステムの地域情報で定義されている）オフセット地元からなるインスタンスを。

• DateTimeOffset.UtcNow静的メソッドが返されます DateTimeOffset（あなたがグリニッジにあったかのように）UTCの現在時刻からなるインスタンスを。

他の有用な種類がありタイムゾーンとのTimeZoneInfoクラス。

.NETでこれに苦労している人は、使用する価値があるDateTimeOffsetかどうか、および/またはTimeZoneInfoあなたの価値があるかどうかを確認してください。

IANA / Olsonタイムゾーンを使用する場合、または組み込みタイプがニーズに不十分である場合は、.NET用のはるかにスマートな日付と時刻のAPIを提供するNoda Timeをチェックしてください。

ビジネスルールは常に市民時間で機能する必要があります（別の方法で規定されている法律がない限り）。市民時間は混乱していることに注意してください。しかし、それは人々が使用するものであるため、重要です。

内部的には、タイムスタンプを民生時間秒からエポックのようなものに保ちます。エポックは、問題、特に（私は賛成しませんUnixエポックを）が、それは代替よりもメイク物事を簡単行います。うるう秒は、本当に必要なこと（衛星追跡など）をしていない限り、存在しないふりをします。タイムスタンプと表示時間のマッピングは、DSTルールを適用する必要がある唯一のポイントです。規則は頻繁に変更されるため（グローバルレベルで、年に数回、政治家を非難します）、マッピングをハードコーディングしないようにしてください。オルソンのTZデータベースは非常に貴重です。

不正確または少なくとも混乱しているように見える2つのことを指摘したかっただけです。

夏時間の影響を受けない統一規格に従って常に時間を維持します。GMTとUTCは別の人から言及されていますが、UTCが最も頻繁に言及されているようです。

（ほぼ）すべての実用的なコンピューティング目的で、UTCは実際にはGMTです。小数秒のタイムスタンプが表示されない限り、この区別を冗長にするGMTを扱っています。

タイムスタンプを保存するときに、現地時間のオフセットをそのまま（DSTオフセットを含む）含めます。

タイムスタンプは常にGMTで表されるため、オフセットはありません。

これが私の経験です：-

（サードパーティのライブラリは必要ありません）

• サーバー側では、ユーザー、サーバー、タイムゾーン、またはDSTの場所に関係なく、データベース内のすべての日付/時刻値が単一の標準になるように、時刻をUTC形式で保存します。
• UIレイヤーまたはユーザーに送信される電子メールでは、ユーザーごとに時間を表示する必要があります。さらに言えば、ユーザーのローカルタイムになるデータベースのUTC値にこのオフセットを追加できるように、ユーザーのタイムゾーンオフセットが必要です。ユーザーがサインアップするときにユーザーのタイムゾーンオフセットを取得するか、Webおよびモバイルプラットフォームでそれらを自動検出することができます。Webサイトの場合、JavaScriptの関数getTimezoneOffset（）メソッドはバージョン1.0以降の標準であり、すべてのブラウザーと互換性があります。（参照：http : //www.w3schools.com/jsref/jsref_getTimezoneOffset.asp）

ComputerphileチャンネルのYouTubeでのタイムゾーンに関するトムスコットのビデオにも、このトピックに関するわかりやすい説明があります。例は次のとおりです。

• サモア（太平洋の島）は、オーストラリアとニュージーランドとの取引を容易にするために、タイムゾーンを24時間進めています。
• 西岸2つの人口集団が異なるタイムゾーンに従っている
• 18世紀はユリウス暦からグレゴリオ 暦に変更されます（20世紀にロシアで起こりました）。

実際、kernel32.dllはSystemTimeToTzSpecificLocationをエクスポートしません。ただし、次の2つはエクスポートされます：SystemTimeToTzSpecificLocalTimeおよびTzSpecificLocalTimeToSystemTime ...

次のようなコンストラクタのみに依存しないでください

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

DSTが原因で特定の日時が存在しない場合、例外をスローできます。代わりに、そのような日付を作成するための独自のメソッドを作成してください。それらの中で、DSTが原因で発生するすべての例外をキャッチし、遷移オフセットで必要な時間を調整します。DSTは、タイムゾーンに応じて、異なる日付および異なる時間に発生する場合があります（ブラジルでは真夜中であっても）。

処理時間が説明された大きな混乱であり、あなたが満足することは決してできないことを証明するためのほんの一例です。このページのいくつかの箇所では、うるう秒は無視されています。

数年前、AndroidオペレーティングシステムはGPS衛星を使用してUTC時間の参照を取得しましたが、GPS衛星がうるう秒を使用しないという事実を無視しました。Appleの電話ユーザーとAndroidの電話ユーザーが約15秒間隔でカウントダウンを行った大晦日に混乱が生じるまで、誰も気づきませんでした。

私はそれが修正されたと思いますが、これらの「細かい詳細」がいつあなたを悩ませるために戻ってくるのかは決してわかりません。

• UTCオフセット（またはタイムゾーンへの参照）なしで現地時間を保存しないでください。これを行わない方法の例として、FAT32と struct tm Cが。¹
• タイムゾーンは以下の組み合わせであることを理解する
  • UTCオフセットのセット（例：冬は+0100、夏は+0200）
  • 切り替えが発生するときの規則（これは時間の経過とともに変化する可能性があります。たとえば、1990年代にEUは切り替えを3月と10月の最後の日曜日の02:00標準時間/ 03：00 DSTであると調和させました。以前はこれが異なっていました。加盟国間）。

of一部の実装でstruct tmはUTCオフセットが保存されますが、これは標準にはなりません。

データベース（特にMySQLですが、これはほとんどのデータベースに当てはまります）を扱う際に、UTCを格納するのは難しいと感じました。

• データベースは通常、デフォルトでサーバーの日時（つまり、CURRENT_TIMESTAMP）で動作します。
• サーバーのタイムゾーンを変更できない場合があります。
• タイムゾーンを変更できる場合でも、サーバーのタイムゾーンがローカルであることを期待するサードパーティのコードがある可能性があります。

サーバーの日付と時刻をデータベースに格納し、格納された日付と時刻をデータベースでSQLステートメントのUTC（つまり、UNIX_TIMESTAMP（））に変換し直すほうが簡単であることがわかりました。その後、コードで日時をUTCとして使用できます。

サーバーとすべてのコードを100％制御している場合は、サーバーのタイムゾーンをUTCに変更することをお勧めします。