用户问“昨天上海门店收了多少款”，智能问数系统即使选对表、写出合法 SQL，也可能给出错误答案。问题不一定在模型推理：如果系统把 UTC 日期当成本地业务日，或者把每一天都当作二十四小时，正确的聚合函数也会统计错误的记录。
先把三个不同概念写进数据契约
事件时刻是时间轴上的一个点，例如某笔支付在 UTC 的发生时间。本地钟表时间是这个时刻在指定地区的显示方式。业务日期则是组织规则赋予事件的归属日，例如上海门店午夜切日，另一个仓库可能早上六点切日。三者相关，却不能用一个没有说明的日期字段互相替代。
在接入前确定事件语义：下单、支付成功、退款确认还是采集到达时间？同时记录来源时区、是否带偏移量、业务日界线和采用的日历规则。报告跨多个门店时，还要明确按各门店本地日汇总，还是按总部统一时间窗口汇总。两种口径可能都合理，但回答的是不同问题。
智能问数的语义层应把这些选择变成可审查配置。比如“实收金额”绑定支付成功时刻、门店经营时区及退款口径。自然语言里的“昨天”还需要一个明确的查询基准时间和报告时区，不能让模型依据服务器当前日期自行补全。无法确定口径时应展示缺项，而不是生成一个看似确定的金额。
UTC 保存时刻，不替你保存原始时区
PostgreSQL 17 文档说明，带时区时间戳会转换到 UTC 保存，原始输入时区不会保留；输出时按当前会话 TimeZone 显示。[1] 因此，使用 timestamptz 可以表达时刻，却不能据此反推出客户当时属于哪一经营时区。若业务需要，应另外保留来源地区标识、原始文本与适用的时区规则版本。
同一文档也指出，不带时区的 timestamp 会忽略输入中的时区提示，而带时区输入若缺少时区，则会按会话配置解释。[1] 这意味着不能只看字符串中出现了加号或 Z 就认定入库正确。字段类型、解析代码与连接会话必须一起核对；测试环境和生产环境的默认时区不同，可能让同一批输入产生不同结果。
一个实用接入契约是保存 event_at_utc、source_timezone、raw_event_time 和解析状态。来源已给出可靠偏移量时，可确定事件时刻；只有本地时间时，必须结合来源规则解释。IANA 地区名能够表达随日期变化的规则，固定偏移量只能表达相应偏移，二者不要混作同一种长期日历配置。上述字段是建议设计，不是数据库强制模式。
先构造本地日边界，再分别转换成 UTC
查询一个业务日时，先在报告时区构造该日开始与次日开始，再把两个边界各自转换到 UTC，按“事件时刻大于等于开始，且小于结束”的半开区间过滤。结束边界不包含，才能避免相邻日期重复统计恰好落在午夜的记录。不要把一天结束写成 23:59:59，因为数据精度可能超过秒。
以北京时间 2026 年 10 月 16 日午夜切日为构造算例，UTC 窗口是 10 月 15 日 16:00 至 10 月 16 日 16:00，不含右端。假设四笔收款依次发生在窗口前一秒、左端、右端前一秒、右端，金额分别为 100、200、300、400。正确业务日合计是 500；若直接筛 UTC 的 10 月 16 日，会选中后两笔，得到 700。
实现时可以在应用中生成两个带时区参数，再用 event_at >= start_utc AND event_at < end_utc 查询。列和参数须表达同一时间类型，参数化传入，不能把未经校验的自然语言拼进 SQL。对有时间索引的系统，这通常也比对每行先做日期转换更容易形成范围扫描，但是否命中索引仍须查看实际执行计划，不在这里承诺性能。
如果业务规定六点切日，应构造当地当日六点与次日六点，再分别转换。跨夏令时变化时，不能简单从 UTC 时刻减六小时后取日期。节假日或特殊营业日另由有版本的业务日历定义；时间转换库并不知道企业什么时候结账。
夏令时让一天不总是二十四小时
使用 Python zoneinfo 按 America/New_York 规则核对边界，2025 年 3 月 9 日的当地午夜对应 UTC 05:00，次日午夜对应 UTC 次日 04:00，间隔 23 小时。2025 年 11 月 2 日的当地午夜对应 UTC 04:00，次日午夜对应 UTC 次日 05:00，间隔 25 小时。这些是已核对的日历转换示例，不是业务性能测试，也不适用于所有地区。
因此，不应在已经转换的 UTC 起点上固定加二十四小时来生成本地日终点。该错误在大部分日期不出现，恰恰容易通过只测试普通工作日的验收。按小时计算速率时，还要说明分母采用真实经过小时还是标准营业小时；日总额本身不应为了凑成二十四小时而自动缩放。
秋季回拨还会让同一个本地钟表时间出现两次。例如纽约 2025 年 11 月 2 日 01:30 可以对应 UTC 05:30 或 06:30。只有“01:30”这一原始值无法确定是哪一次。春季前拨则会产生不存在的本地时间。正确措施是向来源获取偏移量或其他可靠证据，无法消歧时隔离记录并标记原因。
不要用静默修正掩盖来源缺陷
pandas 的 tz_localize 为无时区时间赋予解释；处理列值时应使用相应的 Series.dt 方法，而不是误以为 DataFrame 方法会转换所有时间列。官方文档为歧义与不存在的时间提供显式策略，默认会报错。[2] 对已确定的时刻换一个地区显示，应使用时区转换，而不是重新本地化。
ambiguous 的推断依赖序列等条件，不是从一个孤立字符串恢复真实时刻的魔法。将不存在的时间向前移动可以满足某种业务规则，但这已经修改了时间含义，必须记录规则及影响数量，不能当作原始事实。建议生产入口默认拒绝无法解释的时间，把明确批准的修正规则与原始值一起留存。
Python zoneinfo 使用系统时区数据库，或在缺少系统数据时使用 tzdata 包；它本身不附带独立的时区数据。[3] 团队应记录部署所用规则版本，并在不同环境使用一致的数据来源。升级之后抽查历史边界和未来预约时间，区分已经确定的事件时刻与仍需按当地规则解释的预约钟表时间，不能无差别重算全部历史记录。
把验收做成边界用例与金额对账
至少覆盖普通日、跨月跨年、窗口左右端点、夏令时前拨与回拨、缺少时区和非法时间。为每个用例写出原始输入、来源时区、预期 UTC 时刻、业务日期、是否拒绝及原因。左右相邻两天的归属应没有交集，也没有遗漏；同一事件在不同显示时区下应保持同一时刻。
再做聚合对账：固定一组构造交易，分别以人工列出的成员清单和生产查询计算笔数与金额。上文四笔交易应有且仅有中间两笔进入窗口。增加重复输入、退款及晚到数据时，分别验证幂等、金额定义和刷新规则，避免将其他数据问题错归为时区问题。将数据库会话切到另一时区再运行一次，显式边界查询应保持同一结果。
如果报表还要回答“当时属于哪个区域或客户等级”，应继续处理历史归属与时态关联；正确的业务日不能替代正确的历史维度。时间验收解决的是哪些事件属于这个窗口，维度验收解决的是这些事件按什么属性归类。将两层分别验证，才容易定位偏差。
上线时展示解析失败数量、歧义记录数量及迟到记录对已结算日期的影响。业务方确认日界线和事件口径，数据团队负责转换与边界测试，AI 团队负责把自然语言绑定到已验证定义。智能问数应生成可解释的口径与查询，而不是让每一次提问重新决定时间规则。