datetime.strptime()解析失败主因是格式不匹配，如'2023-5-1'需用'%Y-%-m-%-d'（Linux/macOS）或补零；跨平台strftime()避免%-m/-d，改用dt.month/day拼接；时区须统一为aware对象，推荐zoneinfo并转UTC比较。
datetime.strptime() 解析失败的常见原因
报错 ValueError: time data '2023-05-1' does not match format '%Y-%m-%d' 是最典型的问题：输入字符串和格式串不严格对齐，哪怕少一个零（如 '2023-5-1'）也会崩。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
strptime()前先确认输入是否补零——'2023-05-01'和'2023-5-1'必须用不同格式串，前者是'%Y-%m-%d'，后者得用'%Y-%-m-%-d'（Linux/macOS）或手动正则补零（Windows 不支持%-m） - 别硬刚复杂格式，遇到
'May 1st, 2023'这类自然语言日期，直接换dateutil.parser.parse()，它比strptime()容错强得多 - 批量处理时加
try/except捕获ValueError，避免单条脏数据中断整个流程
strftime() 输出格式中容易忽略的平台差异
strftime() 的 %-d、%-m 在 Windows 上会直接抛 ValueError，因为 MSVCRT 不支持这种去零写法。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 跨平台输出不带前导零的日期（如
'2023-5-1'），改用dt.day、dt.month拼接：f"{dt.year}-{dt.month}-{dt.day}" - 如果必须用
strftime()，统一用'%Y-%m-%d'这类标准格式，再用.lstrip('0')或正则后处理（但注意年份不能去零） -
%f表示微秒，不是毫秒；要毫秒得自己算：dt.microsecond // 1000
时区处理不当导致时间偏移几小时
没显式指定时区的 datetime 对象默认是“naive”类型，一旦和带时区（aware）对象运算或传给某些库（如 pytz、zoneinfo），就会报 TypeError: can't compare naive and aware datetime。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
立即学习“Python免费学习笔记（深入）”；
- Python 3.9+ 优先用
zoneinfo.ZoneInfo，比如dt.replace(tzinfo=ZoneInfo("Asia/Shanghai"))；老版本用pytz.timezone("Asia/Shanghai").localize(dt) - 从字符串解析带时区的时间（如
'2023-05-01T12:00:00+08:00'），直接用datetime.fromisoformat()，它能自动识别+08:00并返回aware对象 - 别用
datetime.utcnow()当本地时间用——它不带时区信息，且已弃用；改用datetime.now(ZoneInfo("UTC"))
字符串转 datetime 后做比较却结果反直觉
两个 datetime 对象比较大小，表面看没问题，但若一个是 UTC 时间、一个是本地时间（又没时区信息），数值上可能 2023-05-01 12:00 小于 2023-05-01 11:00——因为后者其实是 UTC 时间，对应本地 19:00。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有参与比较或计算的时间，必须统一成同一时区下的
aware对象；推荐全部转成 UTC 再比：dt.astimezone(ZoneInfo("UTC")) - 数据库读出的时间字段，留意驱动是否自动加了时区（如 psycopg2 默认返回
aware，sqlite3 默认naive），别假设一致 - 用
datetime.timestamp()转时间戳前，确保对象是aware，否则在夏令时切换日附近可能出错
时区和 naive/aware 的边界最模糊，一不留神就埋进生产环境里，跑几天才暴露。宁可多写一行 astimezone()，也别赌“应该没问题”。
