時區和靈敏度

1）基本原則

UTC作為運輸和存儲。所有服務器計時器和排序密鑰都在UTC中。轉換為本地「鋼」時間-在邊緣（edge/UI）或專用格式服務中。
區域≠位移。「歐洲/基輔」不僅僅是「UTC+02：00」：規則會隨著時間的推移而變化。將IANA ID （tzdb）存儲在用戶/對象配置文件中而不是「+03：00」。
明確區分時鐘。

Wall clock（人類時間，受到DST的影響）。
UTC時鐘（通用量表）。
單調時鐘（用於測量持續時間和時間）。切勿在「墻壁」時鐘上計算時間。
相似性和對時間抖動的耐受性。系統必須正確地經歷小的NTP/位移跳躍。

2）數據模型和API合同

事件：「occurred_at」（UTC，RFC 3339），「timezone」（IANA），可選的「wall_time」（本地創建時保留位移）。
時間：在UTC中使用半封閉間隔「［開始，結束）」；對於可讀的時間表，存儲原始表達式+區域。
重復規則：序列化為RRULE/cron等效項+IANA區域。計劃委派了解DST的引擎。
API中的時間格式：ISO 8601/RFC 3339帶有明確的「Z」或偏移，例如「2025-10-31T17：00：00Z」。不要在沒有偏移的情況下傳輸「浮動」行。
轉化：更改業務時間規則（例如，將國家/地區轉換為永久性UTC+1）是配置遷移和重新計算時間表；在版本圖中考慮。

3）夏季時間（DST）： ambiguitetes和跳過

重復的本地時間。在秋天，本地「02：30」可能發生兩次。該區域的規劃者必須區分「2025-10-26 T02： 30+03」和「2025-10-26 T02： 30+02」。
錯過了本地時間。在春季，分鐘間隔「跳過」（例如「02：00-03：00」不存在）。計劃者必須定義策略：移至「03：00」，跳過或「盡快」執行。
建議：將作業存儲為「本地規則+區域」,實際實例會提前在UTC中實現（滾動窗口）,並將選定策略提交到DST。

4) Leap seconds и time smear

Leap second.有時會將添加秒插入到UTC中。大多數業務流程不應「看到」23：59：60。
Smear（塗鴉）。某些環境會輕輕地將調整分配到窗口（例如12小時±），以避免跳躍。
實踐：協調整個群集的統一時間策略（NTP/smire）,將其寫入元數據並保存在運行手冊中。

5）規劃師和cron模式

「簡單cron」的危險。經典cron不知道DST和IANA區域。使用將時間表綁定到區域的引擎（Quartz類、基於雲的Scheduler服務、Kubernetes CronJob 以及通過控制器/Addmission連接的區域）。
計劃實現。為了實現可靠性,在UTC中實現最近的N發射（例如,7-30天）,存儲cursor並在DST中確定策略。
任務的難度。Ключ deduplication: `(job_id, scheduled_at_utc)`;重新啟動不應復制副作用。
時鐘滑動。如果出現長時間停頓/事件,請決定是抓住（執行跳過）還是跳過。配置每個工作。

6）協議和隊列中的時間

事件輪胎（Kafka/Pulsar）。分別存儲「event_time」和「ingest_time」。對於回顧性重新計算,請使用「event_time」。
相同的消費者。重新交付時,重點關註事件密鑰和「event_time」而不是批次偏移。
排序和窗口。「在本地存儲時間的24小時內」窗口計算為特定日期從特定區域的本地規則獲得的UTC間隔。

7） Logi, Traces,度量

統一的時間區標準：UTC中的所有技術日誌和指標（指定「Z」）。在dashbords中顯示-本地化為用戶。
跟蹤：在單調時鐘上傳輸「trace_start_utc」、「duration_ms」。切勿減去「墻壁」時間表。
業務報告：在域區域（例如，法國稅的「歐洲/巴黎」）而不是UTC上形成「一天」。明確記錄。

8）自定義配置文件和內容

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).

多元化實體：對於命令/組織，獨立於參與者的個人區域，保留「域區域」（例如商店/法人實體）。
符號化：計算用戶區域中的「安靜時鐘」；從UTC窗口發送shedulite，並具有DST安全性。

9）反模式

僅存儲本地時間而不偏移/區域。
硬繞過「+hh： mm」位移而不是IANA ID。
通過兩個「墻壁」時間表的差異來計算持續時間。
沒有區域/DST支持的cron計劃。
在標準要求本地區域時,在UTC進行「每日」分析。
假設區域規則不變（各國正在改變時間政策）。

10）時間測試

受控時鐘。將「時鐘」註入代碼（Clock/TimeProvider）以進行確定性測試。

• 過渡到夏季/冬季時間（雙打/跳過）。
• 在區域之間移動用戶（更改「preferred_timezone」）。
• 將規則更改為tzdb（基數更新-回歸測試）。
• NTP偏移，延遲事件傳遞。
• Fazzi測試。隨機區域，日期，格式；與參考庫的比較。

11）可觀察性和操作

Alerts： NTP同步、tzdb更新滯後、DST中「未完成」cron任務激增。
Dashbords：事件按區域/本地日分布；catch-up/skip計數器。
Runbook：司法管轄區改變時間規則的程序；tzdb更新順序；與時間表所有者的溝通。

12）實現模式

Time Normalization Gateway.微妙的服務,將傳入時間正常化到RFC 3339 UTC,驗證區域（IANA）和補充上下文。
Local-Day Builder.考慮到DST，從「本地日」和區域構建精確的UTC邊界「［start_utc，end_utc）」的庫/服務。
Schedule Materializer.將規則存儲為「本地表達式+區域」的調度程序將未來實例化為UTC並管理沖突/跳過。
Dual-Timestamp Events.帶有「occurred_at_utc」、「wall_time_local」和「timezone」字段的事件。對於UI，本地替換為UTC。

13）建築師支票清單

1.UTC到處存儲嗎?

2.實體是否具有IANA區域和域數據策略?

3.計劃者是否了解DST並在UTC中實現實例化?

4.徽標/度量標準在UTC中；報告-在域區域?

5.Taymauts/retrai-單調手表？

6.tzdb更新是否自動化和監控?

7.測試是否涵蓋規則更改，雙打/跳過分鐘？

14）迷你食譜（偽代碼）

將本地「工作日」轉換為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 }

特效任務啟動密鑰

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

15）安全性和合規性

審計：存儲兩個時間投影（UTC和本地），使用戶索賠（「我承諾直到利馬晚上11點」）與服務器年表保持一致。
監管：報告期在要求的區域（稅收、負責任的遊戲限制、「按小時」營銷限制）中形成。
隱私：時區-個人設置，但不準確識別數據；作為一般隱私政策的一部分進行處理。

二.結論

「時間敏感性」不是關於日期格式，而是關於責任的架構邊界：在哪裏存儲，在哪裏轉換，如何計劃和如何證明正確性。UTC級別的統一，明確的IANA區域，合格的規劃師，雙時鐘和單調時鐘將時間從事件源轉換為可預測的基礎設施服務。

• GeoDNS和地理路由；負載平衡；時間事件的可觀察性；Cron模式和時間表實現；區域限制和當地報告日。