pandas读CSV时parse_dates默认丢时区，需用dtype={"col": "datetime64[ns, UTC]"}（≥2.0）或date_parser=lambda x: pd.to_datetime(x, utc=True）；MySQL应设time_zone='+00:00'或改用TIMESTAMP；后端须显式解析并转UTC再存库。
Python pandas 读 CSV 时 parse_dates 不保留时区怎么办
默认情况下，pandas.read_csv() 解析时间列会丢掉原始时区（比如 "2024-03-15t14:23:00+08:00" 变成 datetime64[ns] 但无 tzinfo），后续计算或比对就容易错位。
根本原因是 parse_dates 默认不启用时区感知解析，得手动指定 utc=False 并配合 date_parser 或升级到 pandas 2.0+ 用 dtype 控制：
- 如果数据里带完整 ISO 时区偏移（如
+08:00），优先用dtype={"ts": "datetime64[ns, UTC]"}+convert_dtypes()自动推断（pandas ≥ 2.0） - 老版本或格式不规范时，改用
date_parser=lambda x: pd.to_datetime(x, utc=True)，强制转为 UTC-aware - 别依赖
infer_datetime_format=True—— 它会跳过时区解析，哪怕字符串里有+08:00
MySQL 导入后 datetime 字段全变成服务器本地时间
MySQL 的 DATETIME 类型本身不存时区，客户端插入带时区的时间（如 2024-03-15 14:23:00+08:00）时，驱动常自动转成服务端 time_zone 设置下的本地值，导致上海时间写进数据库后查出来像北京时间但其实是按系统时区硬转的。
解决路径只有两条，且必须选其一：
- 服务端统一设为
+00:00（UTC），所有应用层传入前转 UTC，读出后再转本地 —— 这是最稳的，避免跨环境漂移 - 改用
TIMESTAMP类型（它会自动按time_zone转换存储），但注意：它范围小（1970–2038）、精度低、且不能设为 NULL 默认值（MySQL 8.0.28+ 除外） - 千万别在 SQL 里用
NOW()或CURRENT_TIMESTAMP插入 —— 它们直接取 server time，和业务时区无关
Flask/FastAPI 接口接收时间参数后存 DB 前没做时区归一化
前端传 {"event_time": "2024-03-15T14:23:00+08:00"}，后端用 datetime.fromisoformat() 解析，结果得到一个带 +08:00 的 naive 对象？不对 —— Python 3.7+ 的 fromisoformat() 确实能解析时区，但很多框架（如 Pydantic v1）默认会 strip 掉 tzinfo，导致隐性丢失。
关键动作是「显式检查」和「强制归一」：
- 收到时间字符串后，立刻用
dateutil.parser.isoparse()或pd.to_datetime(..., utc=True)解析，确认.tzinfo is not None - 统一转成 UTC：
dt.astimezone(timezone.utc)，再存入数据库（无论字段类型是DATETIME还是TIMESTAMP） - FastAPI 中若用 Pydantic v2，记得字段声明为
datetime类型并配examples测试带时区输入；v1 则必须重写__pydantic_validator__或加自定义@field_validator
Logstash / Airflow / Spark 等工具导入时忽略原始时区字段
这类工具默认把时间当字符串或本地时间处理，尤其当源数据是 JSON 或 CSV 且含 "ts": "2024-03-15T14:23:00+08:00"，Logstash 的 date filter 若没配 timezone 参数，就会当成 UTC 解析；Spark 的 to_timestamp() 函数默认也不识别时区偏移。
每种工具要打补丁的位置不同：
- Logstash：
date { match => ["ts", "ISO8601"] timezone => "UTC" }—— 注意这里填的是目标时区，不是源时区；如果源是+08:00，应先用mutate + gsub把字符串标准化为UTC格式再 parse - Spark（PySpark）：
df.withColumn("ts_utc", to_timestamp(col("ts"), "yyyy-MM-dd'T'HH:mm:ss.SSSXXX").cast("timestamp"))，其中XXX才能匹配+08:00，用SSS而非SSSS防止毫秒位数不一致报错 - Airflow 的
PythonOperator里若调用 pandas，记得在read_xxx后立刻跑df["ts"].dt.tz_convert("UTC")，别等写入前才转
时区问题从来不是“解析对了就行”，而是从数据源头开始，每一层都要明确自己处理的是 UTC 还是本地时间、有没有做转换、转换依据是什么。最容易被绕开的点是：日志打点时间、数据库服务器 time_zone、应用部署机器的 /etc/timezone、以及中间件（如 Nginx）记录的 $time_iso8601 —— 它们可能各自为政，却共享同一个时间字段名。
