BigQuery加载Pandas DataFrame时将时间戳识别为Unix纳秒而非微秒的问题排查

这个问题我之前也碰到过类似场景，结合你的描述，大概率是客户端依赖更新或BigQuery服务端隐性调整导致的，下面拆解几个可能的核心原因：

1. 依赖库版本变更 #

最常见的触发点是你使用的pandas、google-cloud-bigquery或者底层序列化库pyarrow发生了版本升级：

• 比如google-cloud-bigquery的某个更新版本中，调整了带时区Timestamp的序列化逻辑——原本将时间戳转换为微秒级数值，现在误转为纳秒级数值，导致BigQuery解析时把纳秒当成微秒计算，时间戳直接超出[0001-01-01, 9999-12-31]的合法范围。
• pyarrow的序列化规则变更也可能引发问题：如果底层把Timestamp的精度从微秒改成了纳秒，而BigQuery接收时没有做自动转换，就会触发这个错误。

2. BigQuery服务端的隐性更新 #

Google经常会对BigQuery的后台逻辑做小版本调整，比如：

• 之前BigQuery可能会自动识别时间戳数值的精度（比如看到16位数值按微秒处理，19位按纳秒），但最近的更新中，解析规则变得更严格，默认按纳秒处理，导致原本正确的微秒数值被放大1000倍，直接超出范围。
• 或者对带时区的时间戳解析逻辑做了调整，之前能兼容pytz.FixedOffset类型的时区，现在处理方式变了，导致序列化后的数值精度出错。

3. 数据或加载逻辑的细微变化 #

虽然你说脚本运行了数月，但也可能存在容易忽略的小变动：

• 最近的published_at列生成逻辑有没有调整？比如原本是不带时区的Timestamp，现在变成了带pytz.FixedOffset时区的类型，而这种类型的序列化方式和UTC时区的Timestamp不同，导致精度错误。
• 加载任务的参数有没有隐性变更？比如之前用schema_auto_detect=True，现在因为代码重构改成了手动指定schema，而手动指定的schema中时间戳类型的精度设置有误。

为什么转成字符串能解决问题？ #

当你把Timestamp转成字符串后，BigQuery会按照ISO 8601格式解析时间，这种格式的时间戳是明确的（比如2022-04-28 20:59:51-0700），不会出现微秒/纳秒的混淆，所以能正常识别为合法的时间戳。

建议排查方向 #

• 检查最近的依赖库更新记录（比如查看requirements.txt的变更，或用pip list --outdated确认），回滚到之前的版本验证是否恢复正常。
• 对比之前正常运行时的Timestamp类型和现在的类型，看是否有时区或精度的差异。
• 查看Google Cloud的BigQuery更新日志，确认近期有没有时间戳解析相关的调整。

内容的提问来源于stack exchange，提问作者bigmellow