docs(dw-issues): #15 in_time/billing_date 类型违约(DateTime/UTC vs 契约北京naive)→ 交宿主修

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/dw-data-source-issues.md

@@ -39,6 +39,14 @@
 - **影响**:cold-import 只能看到终态,无法监控 appointment_created/changed/cancelled/fulfilled 等动作事件;爽约率/改约频率/漏斗分析需事件流
 - **诉求**:除患者外用 **append 事件流**(状态变更新增行而不是改原行),或提供独立"状态变更日志表"
 
+### 15. ⏰ 时间字段类型违约:`in_time` / `billing_date` 是 `DateTime`(UTC),其余是北京裸串
+- **契约**:该数仓所有时间 = **北京时间(naive 字符串)**。PAC 据此一律按北京解析 → 存 UTC(PAC 内部恒 UTC)。
+- **违约**:`fact_appointment_out.in_time`、`fact_settlement_out.billing_date` 是 ClickHouse **`DateTime` 类型**(内部 UTC 瞬时),其余时间列(created_date/updated_date/appo_datetime_str/rq…)都是 `String`(北京裸串)。
+- **后果**:CH 把 DateTime 序列化成裸串(如 `in_time` UTC `2025-09-26 03:09:05` = 北京 11:09,无 `Z` 标记)→ PAC 把它当北京裸串又 −8 → 存成 UTC `2025-09-25 19:09`(**比真实慢 8 小时**)。
+  - 实例:患者王振中,真实到诊北京 11:09(=created_date 11:08 吻合),encounter occurred_at 被弄成 UTC 19:09(本地 03:09)→ 与同次 treatment(北京 11:10)跨了 UTC 自然日 → **就诊次数虚增**(2 次,实 1 次),并殃及 lifecycle 分期 / RFM 频次。
+- **PAC 立场**:不为错误数据在算法层做时区兼容(本末倒置)。PAC 内部恒 UTC、按契约(北京 naive)解析,这是对的。
+- **诉求**:DW 把 `in_time` / `billing_date` 改成与其余列一致的**北京 naive 字符串**(或全库统一带 `Z`/offset 的 tz-aware,二选一,别混)。在宿主修正前,这两列派生的时间(尤其 encounter.occurred_at)系统性慢 8h。
+
 ---
 
 ## 🟡 P1 — 数据质量