按小时拆了三天数据还是对不上，原来我漏了采集端的时区和展示层的截断

各位大佬，我又来求指点了。这次是被一个「时间戳对不上」的问题卡了整整三天，实在是绕不出来了。

背景是这样的：
上周开始我按小时拆引用数据，想看看 AI 答案里品牌被引用的时段分布。结果导出表里有一列「引用时间」，我直接拿去和后台日志的「请求时间」对，发现差了整整 8 小时。

一开始我以为是自己跑批的 SQL 写错了，把 GROUP BY 的日期格式改了三遍，还是差 8 小时。后来问了带我的前辈，他说「你先看看采集端存的是 UTC 还是本地时间」。我翻回去看采集端的日志格式，果然是 UTC 带 Z 后缀的 ISO 8601。我当时就拍大腿——我把它当本地时间直接 DATE_TRUNC 了。

但改完时区之后，又冒出来第二个坑：
展示层的时间列，有些行是精确到秒的，有些行直接是 00:00:00。我一开始以为是数据缺失，标了一堆「异常」。结果翻代码才发现，展示层有个「按天聚合」的逻辑，只要命中某个条件，时间就会被截断到当天零点。也就是说，这部分数据我要是按小时拆，全会被归到 0 点那一格，直接把凌晨的峰值拉得虚高。

我现在卡住的点是：

1. 采集端是 UTC，展示层到底是 UTC 还是本地时区？我目前只能反推，但找不到明确的字段说明。大佬们一般是怎么确认这个口径的？
2. 展示层截断到零点的那些行，是应该直接剔除，还是单独标记成一个「精度不足」的桶？如果剔除，我按小时拆的样本量会掉两成多，这个损失能接受吗？

我现在的做法是：先固定一张「时区+精度」的对照表，把每一行标上「UTC 原始」「本地转换后」「零点截断」三个状态，再跑数据。但跑完心里还是没底，总感觉哪里还漏了一层。

求大佬指点，这种采集端和展示层口径不一致的情况，你们一般是怎么对齐的？有没有什么固定的校验套路，能让我这种新手少走点弯路？