☰

夏時間とタイムゾーンのベストプラクティス [終了] 質問する

tag-icon • tag-icon datetime timezone utc dst datetimeoffset
夏時間とタイムゾーンのベストプラクティス [終了] 質問する

私はこの質問とその答えを、夏時間への対応、特に実際の切り替えに対処するための決定的なガイドにしたいと考えています。

追加したいことがあれば、

多くのシステムは正確な時間を維持することに依存していますが、問題は夏時間による時間の変更、つまり時計を進めたり戻したりすることです。

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

  • 夏時間の問題にどのように対処しましたか？
  • あなたのソリューションにはどのような前提が含まれていますか? (ここでコンテキストを探します)

同様に、あるいはそれ以上に重要なこと:

  • 何を試したがうまくいかなかったのですか?
  • なぜ機能しなかったのですか?

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

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

ベストアンサー1

回答とその他のデータの要約: (あなたの回答を追加してください)

する：

  • 正確な時刻を参照する場合は、夏時間の影響を受けない統一された標準に従って時刻を維持します。(この点では GMT と UTC は同等ですが、UTC という用語を使用することをお勧めします。UTC はZulu時間またはZ時間とも呼ばれることに注意してください。)
  • 代わりに、ローカル時間の値を使用して (過去の) 時刻を保持することを選択した場合は、タイムスタンプが後で明確に解釈できるように、UTC からのこの特定の時刻のローカル時間オフセットを含めます (このオフセットは年間を通じて変更される可能性があります)。
  • 場合によっては、 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.timeJava 8 以降の場合。
  • java.timeの機能の多くはJava 6と7にバックポートされています。スリーテンバックポート図書館。
  • さらに初期のAndroid（< 26）向けに適応されたスリーテンABP図書館。
  • これらのプロジェクトは、公式に由緒あることに取って代わりますジョダタイム、 今メンテナンスモード. Joda-Time、ThreeTen-Backport、スリーテンエクストラ、Java.Timeクラス、およびJSR310同じ人物が率いており、スティーブン・コールボーン。
  • 使用する場合。ネット、使用を検討してください野田タイム。
  • Noda Time なしで .NET を使用する場合は、DateTimeOffsetよりも の方が優れた選択肢となることが多いことを考慮してくださいDateTime。
  • Perlを使用する場合は、日付時刻。
  • Python 3.9以降を使用している場合は、組み込みのゾーン情報タイムゾーンを扱う場合は、日付ユーティリティまたは矢印。 年上のピッツライブラリは通常は回避できます。
  • JavaScriptを使用する場合は、古いバージョンの使用を避けてください。モーメントまたは瞬間-タイムゾーンライブラリは、現在積極的にメンテナンスされていないため、Moment.js プロジェクトのステータス詳細については、ルクソン、日付関数、デイ.js、 またはjs-ジョダ。
  • PHP > 5.2 を使用している場合は、、クラスが提供するネイティブのタイムゾーン変換を使用してください。次DateTimeのDateTimeZone使用には注意してくださいDateTimeZone::listAbbreviations()-回答を見るPHPを最新のOlsonデータに保つには、定期的にインストールしてくださいタイムゾーンdbPECL パッケージ。回答を見る。
  • C++を使用する場合は、IANA タイムゾーン データベースこれらには以下が含まれますcctz、集中治療室、 そしてハワード・ヒナントの「tz」ライブラリC++20 では後者が標準<chrono>ライブラリに採用されています。
    • 使ってはいけませんブーストタイムゾーン変換用。そのAPI標準IANA（別名「zoneinfo」）識別子をサポートすると主張しているが、大まかにマッピングする各ゾーンの豊富な変更履歴を考慮せずに、POSIX スタイルのデータに変換します (また、ファイルはメンテナンス対象外になっています)。
  • Rustを使用する場合は、クロノ。
  • ほとんどのビジネス ルールでは、UTC や GMT ではなく常用時間が使用されます。したがって、アプリケーション ロジックを適用する前に、UTC タイムスタンプをローカル タイム ゾーンに変換することを計画してください。
  • タイムゾーンとオフセットは固定されておらず、変更される可能性があることに留意してください。たとえば、歴史的に米国と英国は、同じ日付を使用して「春の早送り」と「秋の早戻し」を行ってきました。しかし、2007 年に米国は時計が変更される日付を変更しました。これは、現在、年間 48 週間でロンドン時間とニューヨーク時間の差が 5 時間、4 週間 (春に 3 週間、秋に 1 週​​間) で 4 時間であることを意味します。複数のゾーンが関係する計算では、このような項目に注意してください。
  • 時間の種類（実際のイベント時間、放送時間、相対時間、履歴時間、繰り返し時間）を考慮し、正しい取得のために保存する必要がある要素（タイムスタンプ、タイムゾーンオフセット、タイムゾーン名）を検討します。この答え。
  • OS、データベース、アプリケーションの tzdata ファイルを、それら自身と他の世界との間で同期させます。
  • サーバーでは、ハードウェア クロックと OS クロックをローカル タイム ゾーンではなく UTC に設定します。
  • 前の箇条書きに関係なく、 Web サイトを含むサーバー側コードでは、サーバーのローカル タイム ゾーンが特定のものであると想定しないでください。回答を見る。
  • タイムゾーンは、構成ファイルの設定やデフォルトを通じてグローバルに操作するのではなく、アプリケーション コード内でケースバイケースで操作することをお勧めします。
  • 使用NTPA のすべてのサーバー上のサービス。
  • 使用する場合ファット32タイムスタンプは UTC ではなく現地時間で保存されることに注意してください。
  • 定期的なイベント（毎週のテレビ番組など）を扱う場合は、夏時間によって時間が変わり、タイムゾーンによって異なることに注意してください。
  • 常に日付時刻値をクエリする下限は含む、上限は含まない（>=、<）。

してはいけないこと:

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

テスト:

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

参照：

他の：

  • 夏時間という忌まわしい慣習を終わらせるよう、代表者に働きかけましょう。私たちはいつでも希望を持てます...
  • ロビー活動地球標準時

おすすめ記事