タイムゾーンと感度

1）基本原則

輸送および貯蔵としてUTC。すべてのサーバータイムスタンプとソートキーはUTCにあります。ローカルの「壁」時間への変換-エッジ（エッジ/UI）または専用の書式設定サービスで。
ゾーン≠オフセットします。'Europe/Kyiv'は単に'UTC+02：00'ではありません。「+03：00」ではなく、IANA ID （tzdb）をユーザー/オブジェクトプロファイルに保存します。
明確な時計の区別。

壁時計（人間の時間、DSTの対象）。
UTCクロック（ユニバーサルスケール）。
モノトニッククロック（時間とタイムアウトを測定するための）。ウォールクロックのタイムアウトを計算しないでください。
時間に対する不公平さと寛容さが揺らぎます。システムは小さなNTP/オフセットジャンプを正しく生き残らなければなりません。

2）データモデルとAPI契約

イベント：'occured_at' （UTC、 RFC 3339）、 'timezone' （IANA）、オプション'wall_time'（作成時にオフセットされたローカル）。
Periods： UTCで「［start、 end）」の半閉鎖間隔を使用します。人間が読みやすいスケジュールの場合は、元の式+ゾーンを維持してください。
重複ルール：RRULE/cron等価+IANAゾーンとしてシリアル化します。DSTを理解するエンジンに計画を委任する。
APIのタイムフォーマット：明示的な'Z'またはオフセットを持つISO 8601/RFC 3339（例：'2025-10-31T17： 00： 00Z'）。オフセットなしで浮動小数点を渡さないでください。
バージョン管理：時間のビジネスルールの変更（例えば、国を一定のUTC+1に切り替える）は、構成の移行とスケジュールの再計算です。リリーススキーマで考えてみましょう。

3）夏時間（DST）： あいまいさおよび省略

ローカル時間を複製しました。秋には、地元の「02：30」が2回起こることができます。ゾーン内のプランナーは、'2025-10-26T02： 30+03'と'2025-10-26T02： 30+02'を区別する必要があります。
地元の時間を逃した。春には「ジャンプ」（例えば、'02：00-03：00'は存在しません）。プランナーは戦略を決定する必要があります：'03：00'に移動し、「できるだけ早く」スキップまたは実行します。
推奨事項：ジョブを「ローカルルール+ゾーン」として保存し、実際のインスタンスを事前にUTC（ローリングウィンドウ）で実体化し、選択したポリシーをDSTに固定します。

4）リープセコンドタイムスミア

2番目の跳躍。UTCに余分な秒が挿入されることがあります。ほとんどのビジネスプロセスは「見る」べきではない23：59：60。
スミア。一部の環境では、ジャンプを避けるためにウィンドウごとの調整（例えば、12時間±）を穏やかに配布しています。
練習：クラスタ全体（NTP/smir）の単一のタイムポリシーに同意し、メタデータにログインしてrunbookに保存します。

5）プランナーとcronパターン

"単純なcronの危険性。"クラシッククロンはDSTとIANAゾーンを知らない。スケジュールがゾーンバインドされているエンジンを使用します（Quartzクラス、クラウドスケジューラサービス、コントローラ/管理を介してゾーンを持つKubernetes CronJob）。
スケジュールの具現化。信頼性のために、次のNがUTCで実行されることを具現化し（例えば、7-30日間）、カーソルを保存し、DSTでポリシーを決定します。
タスクのidempotency。Ключ重複排除：'（job_id、 scheduled_at_utc）'；再起動は副作用を複製しないでください。
クロックスリップ。長い休止/インシデントの場合は、キャッチアップするかスキップするかを決定します。ジョブごとに設定します。

6）議定書およびキューの時間

イベントバス（Kafka/Pulsar）。'event_time'と'ingest_time'を別々に保存します。回顧割り当てには'event_time'を使用します。
Idempotent消費者。再配列する場合は、バッチ内のオフセットではなく、イベントキーと'event_time'に焦点を当てます。
並べ替えとウィンドウ。特定の日付の特定のゾーンのローカルルールから取得したUTC間隔として「24時間ローカルストア時間」ウィンドウを計算します。

7）ログ、トレース、メトリック

統一されたタイムゾーン標準：UTC内のすべてのテクニカルログとメトリック（'Z'を示す）。ダッシュボードで表示-ユーザーにローカライズ。
Trace-単調なクロックに'trace_start_utc'、 'duration_ms'を渡します。「壁」タイムスタンプを引かないでください。
ビジネスレポート：ドメインゾーンで「日」を形成する（例：UTCではなく「Europe/Paris」（フランス税込）。はっきりと文書を書く。

8）ユーザープロファイルとコンテンツ

Профиль： 'preferred_timezone' （IANA）、 'preferred_locale'、 'currency'、 'week_start' （Mon/Sun）。
マルチゾーンエンティティ：チーム/組織の場合、参加者の個人ゾーンに関係なく「ドメインゾーン」（店舗/法人など）を保存します。
通知：ユーザーゾーンで「静かな時間」を計算します。DSTセキュリティでUTCウィンドウから送信します。

9）アンチパターン

オフセット/ゾーンなしでローカル時間のみを保存します。
IANA識別子の代わりにハードフラッシュオフセット'+hh： mm'。
2つの「壁」タイムスタンプの違いを通して期間を計算します。
ゾーン/DSTサポートなしのcronで計画します。
標準がローカルゾーンを必要とするUTCで分析を「日ごとに」行います。
ゾーンのルールの不変性を仮定します（国は時間の方針を変更します）。

10）時間のテスト

制御された時間。決定論的テストのために「clock」をコード（Clock/TimeProvider）に注入します。

• 夏時間（ダブ/スキップ）が変わります。
• ユーザーをゾーン間に移動します（'preferred_timezone'を変更します）。
• tzdbのルール変更（基本更新-回帰テスト）。
• NTPオフセット、イベントの遅延配信。
• ファジーテスト。ランダムゾーン、日付、フォーマット；参照ライブラリとの比較。

11） Observabilityおよび操作

アラート：NTPミスアライメント、tzdbアップデートラグ、DSTでの「未充填」cronタスクのバースト。
ダッシュボード：ゾーン/ローカル日ごとのイベントの配布。キャッチアップ/スキップカウンター。
Runbook：管轄内のタイムルールを変更する手順。tzdb update orderはスケジュールオーナーと通信します。

12）実装パターン

タイムノーマライゼーションゲートウェイ。着信時間をRFC 3339 UTCに正規化し、ゾーン（IANA）を検証し、コンテキストを補完する微妙なサービス。
ローカルデイビルダー。DSTを考慮して、「ローカルの日」とゾーンから正確なUTC境界'［start_utc、 end_utc）'を構築するライブラリ/サービス。
Materializerをスケジュールします。「ローカル式+ゾーン」としてルールを格納するスケジューラは、UTCの将来のインスタンスを実現し、衝突/省略を管理します。
デュアルタイムスタンプイベント。フィールド'occurred_at_utc'、 'wall_time_local'、 'timezone'を持つイベント。LocalはUIの代わりに、UTCはシステムの代わりになります。

13）建築家のチェックリスト

1.UTCはどこにでも保存されますか？
2.エンティティにはIANAゾーンとドメインデータポリシーがありますか？
3.スケジューラはDSTを理解し、UTCのインスタンスを具現化しますか？
4.ログ/メトリクス-UTC；レポート-ドメインゾーンで？
5.タイムアウト/リトリート-単調な時計に？
6.tzdbアップデートは自動化され、監視されますか？
7.テストはルールの変更をカバーします？

14）ミニレシピ（擬似コード）

ローカル「workday」をUTC間隔に変換する

function localDayToUtcInterval(dateLocal, tz):
startLocal = combine(dateLocal, 00:00) in tz endLocal  = startLocal + 1 day startUtc  = toUTC(startLocal) // учитывает DST endUtc   = toUTC(endLocal)
return [startUtc, endUtc)

定期的なスケジュールの実現

inputs: rrule, tz, windowStartUtc, windowEndUtc for each localOccurrence in expand(rrule, tz, [windowStartUtc, windowEndUtc] projected to tz):
emit occurrence { scheduled_at_utc = toUTC(localOccurrence), tz }

Idempotentタスクスタートキー

dedupe_key = hash(job_id + scheduled_at_utc.toString())

15）安全性とコンプライアンス

監査：UTCとローカルの両方のタイムプロジェクションを保持して、ユーザーの要求（「I was confident before 11 pm Lima」）とサーバーの年表を調整します。
規制：報告期間は、必要なゾーン（税金、責任あるゲーム制限、マーケティング制限「時間ごとに」）に形成されます。
プライバシー：タイムゾーン-個人設定、しかし正確にデータを識別しません。共通のプライバシーポリシー内での処理。

おわりに

「時間感度」は日付形式ではなく、どこに保存するか、どこを変換するか、どのように計画するか、どのように正しさを証明するかという建築上の責任の境界についてです。UTC統合、明示的なIANAゾーン、有能なスケジューラ、デュアルタイムスタンプ、単調時計は、インシデントの発生源から時間を予測可能なインフラストラクチャサービスに変換します。

• GeoDNSとジオルーティング；ロードバランシング；時間の経過とともにの出来事の観察可能性；Cronパターンとスケジュールの具現化；地域の制限と地域の報告日。