夏時間とタイムゾーンのベストプラクティス

Question

私はこの質問とそれに対する答えを、特に実際の変化に対処するための、夏時間に対処するための最も確実なガイドにすることを望んでいます。

追加するものがある場合は、実行してください

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

例えば、注文の時間に依存する受注システムにビジネスルールがあります - 時計が変わると、ルールはそれほど明確ではないかもしれません。注文の時間はどのように持続されるべきですか？もちろん無限の数のシナリオがあります - これは単なる実例です。

夏時間の問題にどう対処しましたか。
どのような前提があなたの解決策の一部ですか？（ここでコンテキストを探します）

もっと重要ではないにしても、重要なことです。

うまくいかなかったことを何を試しましたか。
なぜうまくいかなかったのですか。

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

一般的な回答は素晴らしいですが、特に1つのプラットフォームでしか利用できない場合にも詳細を確認したいと思います。

Yuval Adam · Answer

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

Do：

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

しない：

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

テスト：

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

参照：

その他：

代表者にロビー活動を行い、DSTである憎悪を終わらせます。私たちはいつでも望みます...
地球標準時のロビー

bluesmoon · Answer

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

時間の種類

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

イベント時間：例えば、国際的なスポーツイベントが起こる時間、または戴冠式/死など。これはイベントのタイムゾーンに依存し、視聴者のタイムゾーンには依存しません。
テレビ時間：例えば、特定のテレビ番組は、世界中の午後９時現地時間に放送される。あなたのウェブサイトに結果（例えばAmerican Idol）を公開することを考えるときに重要です
相対的な時間：例：この質問は21時間でオープンバウンティクローズを持っています。これは表示が簡単です
定期的な時間：例：DSTが変更された場合でも、テレビ番組は毎週月曜日の午後9時に表示されます。

歴史的/代替的な時間もあります。彼らは標準時に戻ってマッピングしないかもしれないので、これらは厄介です。例：ユリウス日、土星の太陰暦、クリンゴン暦による日付。

UTCで開始/終了タイムスタンプを保存することはうまくいきます。 1の場合は、イベントタイムゾーン名+イベントと一緒に保存されたオフセットが必要です。 2の場合は、各地域に保存されている現地時間の識別子と、視聴者ごとに保存されている現地のタイムゾーン名+オフセットが必要です（クランチ状態の場合はIPから取得することも可能です）。 3の場合、UTC秒で格納し、タイムゾーンは不要です。 4は、グローバルイベントかローカルイベントかに応じて1または2の特殊なケースですが、timestampに作成）を格納する必要もあるので、このイベントが作成される前後にタイムゾーン定義が変更されたか履歴データを表示する必要がある場合、これは必要です。

時間を保存する

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

オフセットと名前

上記の例は次のようになります。

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

この情報により、南アフリカのタイムゾーンの定義が変更された場合でも、2010 WCS決勝が行われた正確な時間を歴史的に判断することができます。andデータベースを照会します。

システム時刻

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

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

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

クライアント

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

トリビア

最後に、政府は時に非常に奇妙なことをするでしょう。

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

わかりました、私はしたと思います。

leonbloy · Answer

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

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

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

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

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

Johnは自分のカレンダーに、datetime 2019-Jul-27, 10:30:00、TZ = 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）は正しいものです。

いくつかのDate/Time APIがこの区別を正しくしています。それらのうち、 Jodatime は、次の（3番目の）Java DateTime API（JSR 310）の基盤です。

ZXX · Answer

どの階層がユーザーと相互作用するのかを正確に把握し、正規表現（UTC）の日時を変更する必要があることを明確にするために、アーキテクチャ上の懸念を明確に分離します。 非UTCの日時は、（ユーザーのローカルタイムゾーンを次の）プレゼンテーションで、UTC時刻は、（バックエンドおよびミッドティアのためのユニークなまま）モデルです。

また、あなたが奉仕するとどこに行を引くん持っていないもの、あなたの実際の聴衆が何を決めます。あなたが実際にそこに重要な顧客を持っていて、そしてその地域だけのために別のユーザー向けサーバーを考えているのでなければ、エキゾチックなカレンダーに触れないでください。

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

歴史的な監査の義務がある場合は、（AZでジョーが9月で2歳前に法案を支払ったときに正確に伝えるように）関与そして、（あなたの変換テーブルがAに変更されるレコードの UTCおよび現地時間の両方を保ちます時間のコース）。

バルクにしていたデータのための時間参照タイムゾーンを定義します - などのファイル、Webサービスなどセイ東海岸の会社がカリフォルニア州のデータセンターを持っている - あなたが尋ねると、彼らは1を想定したのではなく、標準として使用しているものを知る必要がありまたは他の。

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

Jonathan Leffler · Answer

あなたはOlson tzデータベースについて知る必要があります。 ~~ftp://elsie.nci.nih.gov/pub~~ 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ライブラリインタフェースは、この種のものに関してはそれほど恐ろしくは役に立ちません。

Olsonのデータは、A D Olsonが間もなく引退すること、および著作権侵害のためにメンテナに対して訴訟が起こされたこと（一部は棄却されたため）もあって、動いています。タイムゾーンデータベースは現在、 _ iana _ （インターネット割り当て番号局）の支援の下に管理されています。フロントページには 'タイムゾーンデータベース' へのリンクがあります。ディスカッションメーリングリストはtz@iana.orgになりました。お知らせリストはtz-announce@iana.orgです。

oefe · Answer

一般に、 ローカルタイムオフセット（DSTオフセットを含む）を含みます。 格納されたタイムスタンプにUTCだけでは、後で元のタイムゾーン（およびDST設定）でタイムスタンプを表示する場合は不十分です。

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

例えば、適切なフォーマットはタプル（unix time、minutes in offset）または ISO 8601 です。

Richard · Answer

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

一部の国ブラジル、イスラエルは、毎年夏時間を設定します。したがって、DSTがいつ有効になるかを事前に知ることは不可能です。他の人たちはDSTがいつ有効になるかに関して固定（ish）規則を持っています。他の国ではDSTをすべて使用していません。

タイムゾーンは、GMTと1時間の違いである必要はありません。ネパールは+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つ）の両方で、西半球および東半球の国々を必ずテストしてください。

shealtiel · Answer

PHPの場合

PHP> 5.2のDateTimeZoneクラスは、既に言及しているOlson DBに基づいています。そのため、DBではなくPHPでタイムゾーン変換を行っている場合は、作業の対象外（わかりにくい）Olsonファイル.

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

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

Matt Kocaj · Answer

あなたの設計がそれに適応できるなら、 すべて一緒に現地時間の変換を避けなさい！

私はこれを非常におかしなことに聞こえるかもしれませんが、UXについて考えてみてください。さらに考えてみると、タイムゾーン（およびDST）の精度は日付がnow()に近いほど重要です。したがって、日付/日付時刻を+/- 1または2週間の相対形式で表すことができれば、残りの時間は短くなります。日付の多くはUTCである可能性があり、それはユーザーの95％にはあまり重要ではありません。

これにより、すべての日付をUTCに格納し、UTCで相対比較を実行して、相対日付しきい値の外側にユーザーUTCの日付を表示することができます。

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

richardtallent · Answer

私はそれを試していませんが、私が説得力があると思うタイムゾーン調整へのアプローチは次のようになります：

すべてをUTCで保存します。
RegionClassId、StartDateTime、およびOffsetMinutes（int、分単位）の3つの列を持つテーブルTZOffsetsを作成します。

テーブルに、ローカル時刻が変更された日時whenとその量のリストを保存します。表内の地域の数と日付の数は、サポートする必要がある日付の範囲と世界の地域によって異なります。日付には実際の限界までの未来が含まれているはずですが、「歴史的」日付であると考えてください。

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

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

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

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

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

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

さて、このアプローチまたは他のの唯一の欠点は、変換fromGMTへの現地時間は完全ではありません。これは、特定の現地時間のクロックrepeatsに対して負のオフセットを持つDSTの変更があるためです。それに対処する簡単な方法はありません、私は恐れています、それは現地時間を保存することはそもそも悪いニュースです。

Ian Ringrose · Answer

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

23時間と25時間の長さの日は対処するのが面倒なので、7時間または9時間かかる8時間シフトもそうです。問題は、あなたがそれぞれの顧客、あるいは顧客の部署が彼らがこれらの特別な場合に何をするかについて彼らが（しばしば文書化せずに）作成した異なった規則を持っているのをあなたが見つけることです。

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

どんな場合でも、UTCで時刻を記録し、日付/時刻を保存する前に現地時間との間で変換する必要があると思います。しかし、特定の時間がどれくらいかかるかを知ることさえ、サマータイムとタイムゾーンでは難しいかもしれません。

Matt Johnson · Answer

Webサイトや他のバックエンドサービスを含む、 server で実行されるアプリケーションに関しては、サーバーのタイムゾーン設定はアプリケーションによって無視されるべきです。

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

Webサイトを含むサーバー側のコードでは、 never サーバーのローカルタイムゾーンを特に指定しないでください。

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

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

Joon · Answer

私は最近、Webアプリケーションで問題を抱えていました。Ajaxポストバックでサーバー側のコードに返される日時が、配信される日時と異なるという問題がありました。

JavaScriptはタイムゾーンと夏時間を調整していたため、ブラウザによっては夏時間をいつ適用するかの計算が行われていたため、クライアントへのポストバックの日付を文字列として作成したクライアントのJavaScriptコードと関係があります。他の人とは違うようでした。

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

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

Yarin · Answer

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

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

あとはサーバーサイドのdatetimeライブラリを使ったUTC /ローカル変換だけです。行ってもいい...

Andrew B · Answer

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

UTCは夏時間の問題を回避し、同期していないサーバーは診断に時間がかかる予期せぬ結果を引き起こす可能性があります。

paquetp · Answer

FAT32ファイルシステムに保存されているタイムスタンプを扱うときは注意してください - それは常にローカルタイム座標で保持されます（DSTを含みます - msdn記事を参照）。その上で焼けました。

Solyad · Answer

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

UTCベースのシステムを使用していたにもかかわらず、昨年、北米のユーザーの場合、3週間のうち1時間ずつ一貫して時間がずれていました。

結局それはサーバーだったのです。彼らは最新のパッチを適用する必要がありました（ Windows Server 2003 ）。

Jonathan · Answer

PHPの `DateTimeZone::listAbbreviations()` output

このPHPメソッドは、（CESTのような）いくつかの '主要な'タイムゾーンを含む連想配列を返します。それは（ヨーロッパ/アムステルダムのような）より具体的な '地理的な'タイムゾーンを含みます。

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

各タイムゾーンのすべての異なるオフセット/ DST設定（履歴設定を含む）が含まれるようです。

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

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

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

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

vwegert · Answer

DSTをアクティブにして稼働しているデータベースシステムを維持している場合は、秋の移行中にデータベースシステムを停止する必要があるかどうかを慎重に確認してください。 Mandy DBS（または他のシステムも）は同じ（ローカル）時間を2回渡すのは嫌いです。これはまさにあなたが秋に時計を戻すときに起こることです。 SAPはこれを（私見は本当にきちんとした）回避策で解決しました - 時計を戻すのではなく、内部時計を通常の半分の速度で2時間動かすだけです.

Donal Fellows · Answer

ビジネスルールは常に市民時間で動作するようにする必要があります（特に明記されている法律がない限り）。市民時間は混乱であることに注意してください、しかしそれは人々が使うものなのでそれが重要なことです。

内部的には、タイムスタンプをEpochからcivil-time-seconds-from-ofのようなものにしてください。 Epoch は特に重要ではありません（ Unix Epoch を好む）が、代替方法よりも物事が簡単になります。うるう秒あなたが 本当に それらを必要とする何かをしているのでなければ存在しない（例えば衛星追跡）。タイムスタンプと表示されている時間の間のマッピングは、 _ dst _ 規則が適用される唯一のポイントです。規則は頻繁に（グローバルレベルで、年に数回;政治家のせいで）変更されるので、マッピングをハードコーディングしないように気を付けてください。オルソンの TZデータベースは非常に貴重です。

M.A. Hanin · Answer

.NETフレームワーク を使用していますか？もしそうなら、.NET 3.5で追加された DateTimeOffset タイプを紹介しましょう。

この構造体はDateTimeとOffset（TimeSpan）の両方を保持しています。これはDateTimeOffsetインスタンスの日時と世界協定時刻（UTC）の違いを指定します。

DateTimeOffset.Now staticメソッドは、（オペレーティングシステムの地域情報で定義されているように）現在の（ローカル）時間とローカルオフセットからなるDateTimeOffsetインスタンスを返します。
DateTimeOffset.UtcNow静的メソッドは、UTCの現在時刻からなるDateTimeOffsetインスタンスを返します（グリニッジの場合と同じ）。

他の役に立つタイプは TimeZone と TimeZoneInfo クラスです。

Matt Johnson · Answer

.NET でこれに苦しんでいる人のために、DateTimeOffsetやTimeZoneInfoを使うのがあなたの価値があるかどうかを見てください。

IANA/Olsonタイムゾーンを使用したい場合、または組み込み型があなたのニーズには不十分であると思う場合は、 Noda Time を調べてください。

Doc · Answer

これが私の経験です： -

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

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

Alix Axel · Answer

不正確または少なくとも混乱を招く2つのことを指摘したいと思いました。

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

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

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

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

Attila Tanyi · Answer

Tom Scottの YouTubeのタイムゾーンに関するビデオ Computerphileチャンネルにも、このトピックに関する素晴らしい説明があります。例は次のとおりです。

サモア （太平洋の島）オーストラリアとニュージーランドとの取引を容易にするために、タイムゾーンを24時間進めます。
West Bank 。2人の人々が異なるタイムゾーンをフォローしています。
18世紀は ユリウス カレンダから グレゴリオン カレンダ（ロシアでは20世紀に起こった）に変わります。

sebi · Answer

のようなコンストラクタだけに頼らないでください。

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

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

Brad · Answer

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

DavidWalley · Answer

処理時間が説明されている非常に混乱であることを証明するためのほんの一例です。このページのいくつかの箇所でうるう秒は無視されています。

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

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

user149408 · Answer

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

1 struct tmのいくつかの実装はUTCオフセットを格納しますが、これは標準にしませんでした。