pd.to_datetime()转秒级时间戳需显式指定unit='s'，否则默认按纳秒处理导致错误；毫秒用unit='ms'；带时区转换应先utc=True再tz_convert()；避免astype('datetime64[s]')。
用 pd.to_datetime() 直接转，别用 datetime.fromtimestamp()
秒级时间戳（如 1717023600）直接传给 pd.to_datetime() 默认会被当成纳秒处理，结果变成公元 56390 年——这是最常踩的坑。根本原因：Pandas 默认单位是纳秒（unit='ns'），而秒级时间戳需要显式声明单位。
正确做法是加 unit='s' 参数：
import pandas as pd ts = [1717023600, 1717027200] dates = pd.to_datetime(ts, unit='s')
输出就是 DatetimeIndex(['2024-05-30', '2024-05-30'], dtype='datetime64[ns]')，干净且向量化，比循环调 datetime.fromtimestamp() 快一个数量级。
遇到 OverflowError: int too large to convert to float 怎么办
当时间戳是整数但位数过大（比如误把毫秒当秒用，或混入了纳秒值），pd.to_datetime() 在内部转 float 时会溢出。这不是数据问题，是单位错配的信号。
立即学习“Python免费学习笔记（深入）”；
- 先检查时间戳数量级：秒级通常在
1e9量级（如1717023600），毫秒是1e12，纳秒是1e18 - 若确认是毫秒，改用
unit='ms' - 若混有异常大值（如
9999999999999），建议先过滤或用errors='coerce'转为NaT再排查
想保留时区或转为本地时间，utc=True 和 tz_localize() 别混用
秒级时间戳本身无时区信息，它默认代表 UTC 时间。如果你要转成带时区的 datetime，必须分两步：
# 正确：先标定为 UTC，再转换时区
dt_utc = pd.to_datetime(ts, unit='s', utc=True)
dt_beijing = dt_utc.dt.tz_convert('Asia/Shanghai')
<h1>错误：直接 tz_localize 会重复解释时间戳</h1><h1>pd.to_datetime(ts, unit='s').dt.tz_localize('Asia/Shanghai') → 把 2024-05-30 当成本地时间再套时区，结果错 8 小时utc=True 是关键开关，它让 Pandas 知道“这个数字是从 Unix epoch 开始的 UTC 秒数”，后续转换才可靠。
DataFrame 列里有秒级时间戳，astype('datetime64[s]') 不推荐
有人试过 df['ts'].astype('datetime64[s]')，看似简洁，但它有硬伤：
- 生成的是
datetime64[s]类型，精度只到秒，后续做.dt.hour或.dt.floor('min')会报错或行为异常 - 不兼容大多数
dt访问器（如.dt.date、.dt.normalize()） - 不如
pd.to_datetime(df['ts'], unit='s')返回标准datetime64[ns]稳定
哪怕只是临时看日期，也优先走 to_datetime，类型统一、功能完整、不易埋雷。
真正麻烦的不是转换本身，而是时间戳来源不一致：有的来自前端 JS（毫秒）、有的来自 Linux time.time()（秒）、有的来自数据库导出（可能带时区字符串）。动手前先用 df['ts'].describe() 看数值分布，比硬写转换逻辑更省时间。
