dateutil 足够应对简单时间解析与运算，pendulum 和 arrow 性能优势仅在高频构造、链式调用及时区密集场景显现；三者时区行为差异显著，pendulum 最稳健，arrow 次之，dateutil 易受环境影响。
pendulum 和 arrow 都比 dateutil 快，但别急着换
如果你只是解析 "2023-10-05T14:30:00+08:00" 或做简单加减，dateutil 完全够用，而且没额外依赖。pendulum 和 arrow 的性能优势主要体现在高频构造、链式调用、时区转换密集的场景——比如日志时间批量归一化、调度任务循环计算。但它们都基于 pytz 或 zoneinfo（pendulum 2.x 起默认用 zoneinfo），真遇到夏令时边界或历史时区变更（如 "Asia/Shanghai" 在 1992 年前用 UTC+7.5），dateutil 反而更保守可靠。
常见错误现象：pendulum.parse("2000-01-01") 默认按本地时区解释，不是 UTC；而 arrow.get("2000-01-01") 默认是 UTC——这个差异会让跨服务时间对比出错，尤其在微服务间传字符串时间时。
- 用
pendulum.parse()时，显式加tz="UTC"或strict=True避免隐式本地时区污染 -
arrow.get()接受模糊输入（如"now - 2 days"），但pendulum.parse()不支持这种自然语言，得用pendulum.now().subtract(days=2) - 若项目已重度依赖
dateutil.parser.parse()，且不频繁创建对象，升级收益极小，反而增加维护成本
时区处理：pendulum 最省心，arrow 次之，dateutil 最易漏
dateutil 的 tzlocal() 和 gettz() 在容器或 CI 环境里常返回错误时区（比如 UTC 而非宿主机设置），因为依赖 /etc/localtime 符号链接，而 Docker 镜像通常没配这个。pendulum 默认用 zoneinfo（Python 3.9+）或回退到 pytz，自动识别系统时区更稳；arrow 则默认用 dateutil 的时区实现，行为一致。
使用场景：Web API 返回带时区的 ISO 字符串（如 "2024-03-15T09:12:33.456+01:00"），需要转成统一时区再存 DB。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
pendulum.parse("2024-03-15T09:12:33.456+01:00").in_timezone("Asia/Shanghai")—— 一行搞定，且结果仍是pendulum.DateTime，可继续链式操作 -
arrow.get("2024-03-15T09:12:33.456+01:00").to("Asia/Shanghai")—— 同样简洁，但返回arrow.Arrow，和标准库datetime互转需调用.datetime -
dateutil.parser.parse("2024-03-15T09:12:33.456+01:00").astimezone(ZoneInfo("Asia/Shanghai"))—— 多写两步，且ZoneInfo需手动导入，Python backports.zoneinfo
序列化与类型兼容性：dateutil 最“透明”，pendulum 最“封闭”
如果你要把时间对象塞进 JSON、传给 Pandas 或 SQLAlchemy，dateutil 返回的是原生 datetime，零适配成本；pendulum 返回的是自定义类，JSON 序列化直接报 TypeError: Object of type DateTime is not JSON serializable；arrow 好一点，提供 .isoformat() 和 .datetime 属性，但默认不自动降级。
性能影响：pendulum 对象比 datetime 内存占用高约 3–5 倍（因带更多元数据和方法绑定），高频生成（如每秒千次）可能触发 GC 压力。
- 必须 JSON 化 pendulum 对象？用
dt.to_iso8601_string()或str(dt)，别直接json.dumps(dt) - Pandas DataFrame 构造时传 pendulum 对象，会自动转成
datetime64[ns]，但列 dtype 可能变成object而非datetime64，后续.dt访问失败 - arrow 对象用
arrow_obj.datetime拿原生datetime最安全，且无额外开销
Python 版本与维护现状：别踩 pendulum 2.x 的 zoneinfo 陷阱
pendulum 2.0+ 强制用 zoneinfo，但 Python 3.9 以下版本没内置——安装时不会自动装 backports.zoneinfo，运行时才报 ModuleNotFoundError: No module named 'zoneinfo'。arrow 仍默认走 dateutil.tz，兼容性更宽；dateutil 本身对 Python 3.7–3.12 全支持。
容易被忽略的地方：Docker 镜像用 python:3.8-slim 装了 pendulum 2.x，build 成功，run 时崩——因为没装 backports.zoneinfo，也没在 requirements.txt 显式声明。
- 用 pendulum 2.x？在
requirements.txt加一行backports.zoneinfo; python_version - arrow 当前最新版（1.2.3）已停止维护，GitHub 标记为 “read-only”，新项目慎选
-
dateutil更新勤快，最近一次发布（2.8.2）修复了多个 parser 边界 case，比如含毫秒的"2022-01-01T00:00:00.000Z"解析异常
事情说清了就结束
