频道后台导出 8 万条评论后，我把时间戳全对错了

上个月想给自己频道做一次评论情绪回看，从 YouTube Studio 后台导出评论 CSV。频道大概 8 万条评论，时间跨度两年半，环境是 macOS + Python 3.11，最后要灌进本地 SQLite 做查询。导出文件打开看着没问题，但入库后按天聚合，发现 2023 年 11 月有几天评论数为 0，而那几天明明有视频发布。

先看 CSV 里时间列长什么样：

2023-11-03T14:22:07Z

是 UTC，带 Z。我当时的入库代码偷懒，直接字符串截前 10 位当日期：

day = row["published_at"][:10]

问题在于，我频道主要观众在东八区。一条北京时间 11 月 4 日 01:30 的评论，UTC 是 11 月 3 日 17:30，截出来就落到了 3 号。跨年、跨月的那几天，聚合结果整体偏移，看起来就像凭空少了几天。

改成解析后转本地时区再取日期：

from datetime import datetime, timezone
from zoneinfo import ZoneInfo

dt = datetime.fromisoformat(row["published_at"].replace("Z", "+00:00"))
local = dt.astimezone(ZoneInfo("Asia/Shanghai"))
day = local.strftime("%Y-%m-%d")

同时 SQLite 里不再存字符串日期，存 Unix 时间戳，聚合时用 date(ts, 'unixepoch', '+8 hours')，避免同一份数据两种口径。

为什么这么做：评论的“哪一天”对创作者来说默认是本地日历日，不是 UTC 日。平台导出用 UTC 是为了跨区一致，但落到分析层必须选一个展示时区，并且写死在入库那一步，不要留给查询时临时转换。代价是以后如果要按观众所在地分时区统计，得保留原始 UTC 字段，不能只存本地日期。

哪里会失效：一是我只处理了自己频道的东八区口径，如果频道观众大头在美洲，这个默认值就是错的；二是 published_at 偶尔有空值（被删除或过滤的评论），fromisoformat 会直接抛异常，得先判空；三是我最早用 [:10] 的历史数据已经入库，重跑前得先按主键去重，否则会重复计数。这个坑我踩过一次，第二次重跑多出来一批重复行才发现。

现在留一个问题：你们做评论或观看数据聚合时，日期口径是统一存 UTC 查询时转，还是入库就转成本地时区？我目前倾向前者，但查询里到处写时区偏移也很难受。