17370845950

选datetime而非time，因其提供面向人类的日历抽象，支持微秒、时区、ISO格式及日期计算；time仅适用于系统级操作如时间戳获取、休眠和性能计时等轻量场景。

选 time 还是 datetime，关键看你要处理的是“时间点”还是“时间跨度”，以及是否需要时区、日历逻辑或跨平台一致性。

用 time 模块的典型场景

time 更贴近操作系统底层时间接口，适合系统级操作和简单时间戳处理：

• 获取当前 Unix 时间戳（time.time()），尤其用于性能计时、缓存过期、日志打点等对精度要求不高但需轻量的场景
• 解析或格式化固定格式的时间字符串（如 time.strptime("2025-01-01", "%Y-%m-%d")），但仅限 C 标准支持的格式，不支持微秒、时区缩写（如 "PST"）或 ISO 8601 变体
• 休眠控制（time.sleep(0.1)）、测量代码执行耗时（time.perf_counter()）——这些函数与 datetime 无关，也无需日期语义
• 与 C 扩展或旧协议交互时，需直接操作 struct_time 或秒级整数时间戳

用 datetime 模块的典型场景

datetime 提供面向人类的日历抽象，适合业务逻辑中涉及日期计算、格式化、时区转换等：

• 表示具体日期时间（如 datetime.datetime(2025, 12, 25, 14, 30)），支持年月日时分秒+微秒，可做加减运算（+ timedelta(days=7)）
• 解析和生成 ISO 格式（datetime.fromisoformat("2025-12-25T14:30:00.123")）、自定义格式（.strftime("%Y年%m月%d日")），比 time 更灵活、容错更强
• 处理时区：配合 zoneinfo（Python 3.9+）或 pytz，能正确做夏令时转换、跨时区比较（astimezone()）
• 日期范围计算：如“本月第一天”“下周一”“两个日期相差几个工作日”，借助 dateutil 等扩展更自然

边界模糊时的实用建议

两者不是互斥，常需协作。记住几个关键转换点：

• Unix 时间戳 → datetime：datetime.fromtimestamp(1700000000)（本地时区）或 datetime.utcfromtimestamp()（UTC）
• datetime → Unix 时间戳：dt.timestamp()（注意 dt 需带时区信息，否则按本地时区解释）
• 避免用 time.mktime() 处理非本地时区的 struct_time，易出错；优先用 datetime.timestamp()
• 纯时间间隔（如“3小时20分钟”）用 datetime.timedelta，不用 time 中的秒数手动算——语义清晰且支持天/月/年等不同粒度逻辑（虽 month/year 在 timedelta 中不直接支

  

  持，但 dateutil.relativedelta 可补足）

新项目优先考虑 datetime + zoneinfo

Python 3.9 引入 zoneinfo 后，datetime 已能覆盖绝大多数时间需求。除非你在写嵌入式脚本、性能敏感的底层工具，或维护只用秒级时间的老代码，否则不必主动选择 time。它不是过时，而是职责更窄——就像你不会用 os.path 做字符串拼接，也不会用 datetime 做高精度计时。