# 运维时区全局北京 — 设计

## 背景与目标

- 存储与 API 内部继续 **UTC naive**；运维表单与调度执行语义统一为 **Asia/Shanghai（北京时间）**。
- 解决：cron 按 UTC 跑但界面按北京展示；单次与循环时区不一致；审计日期筛选漏北京 0–8 点。

## 方案对比

| 方案 | 说明 | 结论 |
|------|------|------|
| A. UTC 存储 + 北京语义 | runner/表单/日界按北京，DB 仍 UTC | **选用** |
| B. DB 存北京 naive | 与 Agent/JWT/parseApiDateTime 冲突 | 否决 |

## 选定方案

- **SSOT**：`server/utils/display_time.py` 中 `BEIJING_TZ` / `OPERATOR_TZ`。
- **cron_expr**：5 字段按北京墙钟解释；字符串格式不变。
- **fire_at**：UTC naive 入库；表单「02:00 北京」→ 对应 UTC instant。
- **存量**：无 DB 迁移；部署后人工核对调度列表（生产几乎无启用调度）。

## 不改

JWT/TOTP、Agent 心跳与漂移、Redis TTL、告警 Telegram 去重、`created_at` 写入。

## 验收标准

1. cron `0 2 * * *` 在 UTC `18:00`（北京次日 02:00）触发，非 UTC 02:00。
2. 列表 `next_run` 与表单时:分一致（北京）。
3. 单次调度保存后再编辑，时:分回显正确。
4. 审计 `date_from=YYYY-MM-DD` 覆盖北京当日 00:00–23:59。
