时区和灵敏度

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模式和时间表实现；区域限制和当地报告日。