Python datetime库详解：核心对象、格式化与实战技巧

我一直觉得，Python里最容易被低估的标准库就是datetime。平时写脚本、处理日志、做数据分析，时间处理是躲不掉的硬需求。你要是只会用time.time()加加减减，或者靠手写字符串切片去拼日期，那迟早会掉进各种坑里，比如时区错乱、格式解析失败、闰年判断出错。而datetime这个库，就是官方给你的一套完整解决方案，从日期、时间、时间差到时区，全都给你包圆了。这篇文章我就结合自己实际写代码的经验，把这套库从基础对象到高级玩法，再到实战里的坑和技巧，一次给你讲透。

不管你是刚入门Python的新手，还是已经在写业务逻辑的老手，只要你在代码里碰过时间相关的东西，这篇文章都值得你看完。直接说，读完你能收获什么：一是彻底搞清楚date、time、datetime、timedelta这几个核心对象到底怎么用；二是掌握时间格式化、字符串解析、时区转换这类高频操作的规范写法；三是学会避免一堆我自己踩过、也看别人踩过的坑。最后我还会用一个完整的时间处理工具类，把整套知识点串起来。

1. 内容整体设计与思路拆解

1.1 为什么优先选择 datetime 而不是 time 模块

很多初学者会困惑，Python里处理时间为什么要记两套东西——time模块和datetime模块。我的理解是这样：time模块更贴近操作系统层面的时间表示，它主要围绕"时间戳"（Unix timestamp，即从1970年1月1日UTC开始经过的秒数）来工作，适合做性能计时、延时这类底层操作。而datetime模块则更贴近人类的思维习惯，它把时间拆成年、月、日、时、分、秒这些字段，让你能以面向对象的方式去操作和计算时间。简单说，如果你要跟"人类可读的日期"打交道，比如输出"2024-05-20 13:14:00"这种格式，或者计算"下个月15号是星期几"，用datetime就对了，它提供的date、time、datetime、timedelta这四个核心类天生就是干这个的。

我见过不少项目，代码里用time.time()拿到时间戳，然后自己写localtime()转成结构体，再手动拼接字符串。这种写法不是不行，但很累，而且代码可读性差。更重要的是，一旦遇到时间运算（比如加一天、减两小时）或者跨时区解析，手写逻辑会变得极其繁琐且容易出错。datetime把这些复杂性封装好了，你不需要关心底层怎么计算，直接用对象的方法和运算符就行。这也是我在实际开发里一直主推它的原因。

1.2 核心对象关系与应用场景划分

四个核心类各自负责不同的场景，我先给你画个轮廓：

• date：只处理日期，包含年、月、日三个字段。适合生日、节假日、账单日这类不需要时分秒的场景。
• time：只处理时间，包含时、分、秒、微秒，还可以带时区信息。适合每日定时任务、营业时间这类场景。注意，date和time是分开的，datetime才是它俩的合集。
• datetime：日期加时间的完整组合，是最常用的对象。日志时间戳、数据记录、接口请求时间这些全都用它。
• timedelta：时间段对象，表示两个时间点之间的差值。用来做时间加减运算，比如"三天前""两小时后""这个月还剩几天"。

打个比方，date就像日历上撕下来的一页，time像钟表盘上的读数，datetime是日历和钟表的合体，而timedelta就像计时器计量出的时长。你在脑海里有这个画像之后，选型就不容易犹豫了。比如有人问我"Python里怎么计算两个日期相隔多少天"，那思路就非常清晰：先把两个日期字符串解析成date或datetime对象，然后相减得到一个timedelta，再取它的.days属性就行。

2. 核心细节解析与实操要点

2.1 时间对象创建与字段访问的几种姿势

创建时间对象的方式有很多种，我按使用频率给你排个序。最常用的是通过datetime.now()获取当前本地时间，或者用datetime.utcnow()获取当前的UTC时间。这里我必须提醒一句：utcnow()在新版Python里其实已经标记为废弃了，官方推荐用datetime.now(timezone.utc)来替代，因为它返回的是带时区信息的对象，不会让人误以为它是"本地时区"的当前时间。这一处细节很多人没注意到，但非常重要，尤其是在做全球部署或者处理跨时区业务时。

除了拿当前时间，你还经常需要根据已有的年月日时分秒来构造时间对象。直接传参就行：

from datetime import datetime, date, time # 构造一个精确到微秒的完整时间对象 dt = datetime(2024, 5, 20, 13, 14, 0, 123456) print(dt.year, dt.month, dt.day) # 2024 5 20 print(dt.hour, dt.minute, dt.second) # 13 14 0 print(dt.microsecond) # 123456 # 只构造日期部分 d = date(2024, 12, 25) print(d.weekday()) # 2，表示周三（周一为0） print(d.isoweekday()) # 3，表示周三（周一为1） # 只构造时间部分 t = time(23, 59, 59) print(t.hour, t.minute, t.second)

这里有两个小知识点值得展开。一是weekday()和isoweekday()的区别：前者返回0到6，周一对应0；后者返回1到7，周一对应1。很多人喜欢用isoweekday()，因为它更符合中文习惯（周一对应1），而且ISO 8601标准也是这么定义的。二是datetime对象没有weekday()之外的星期名称接口，如果你想输出"星期三"这种中文名，需要自己建一个映射列表，或者用strftime的%A格式化符。这些都是实打实的细节，写业务代码时经常碰到。

2.2 时间格式化与字符串解析的完整对照

时间对象和字符串之间的互转，是日常开发里最频繁的操作。你可能每天都要面对："把日志里的时间戳改成指定格式""从前端传来的时间字符串解析成时间对象存库""把接口返回的ISO时间格式转换成可读格式"。这些全都靠strftime和strptime这两个方法，它们是一对反向操作。

strftime是datetime对象转换成字符串，strptime是字符串解析成datetime对象。二者都依赖一套格式符号。我把最常用的一组整理成表格，方便你随时查：

格式化时要注意一点，%I是12小时制，通常要配合%p（AM/PM）使用，否则下午1点会显示成"01"而不是"13"，容易产生歧义。如果你要生成文件名或者日志前缀，我一般推荐用%Y%m%d_%H%M%S这种紧凑格式，既排序友好又不带空格，不会在shell里引起分词问题。

解析字符串时，最常见的坑就是格式符与实际字符串不匹配。比如字符串是"2024/05/20"，你却写%Y-%m-%d，那strptime直接抛ValueError。这种问题排查其实不难，但新手容易反复踩。我的做法是：能控制输入格式的场景（比如自己生成的时间字符串）尽量统一用一种格式，减少脑力负担；在解析外部数据时，优先尝试ISO 8601格式，因为Python的fromisoformat()方法可以直接处理"2024-05-20T13:14:00"这种标准格式，比strptime看着清爽很多。

2.3 timedelta 运算规则与常见计算场景

timedelta的出现，让时间加减变得像数字加减一样自然。它支持天、秒、微秒三个主要参数，不过为了方便，也允许直接传weeks（会被自动换算成天数）。我常用的几个场景写给你看：

from datetime import datetime, timedelta now = datetime.now() print("当前时间:", now) # 三天前的同一时刻 three_days_ago = now - timedelta(days=3) # 两小时之后的时刻 two_hours_later = now + timedelta(hours=2) # 一周又一天的中午（这个有点骚操作，一般不会这么写） weird = now + timedelta(weeks=1, days=1, hours=12) # 两个时间点之间的差值 another_time = datetime(2024, 1, 1) delta = now - another_time print("距2024年元旦过去了:", delta.days, "天") print("总秒数:", delta.total_seconds())

这里有个关键点需要注意：timedelta内部只存储days、seconds、microseconds三个字段，所以当你访问delta.seconds时，它并不是"总共的秒数"，而是"除整天外剩余的秒数"。如果你想拿到完整的秒数（比如用于计算时间戳差值），应该用total_seconds()方法。这不是概念抠字眼，而是真真切切会踩的坑。我就见过有同事用delta.seconds去算接口耗时，结果碰到耗时超过一天的情况，算出来的数值完全不对。

另外，timedelta还支持与数字相乘、相除，以及取绝对值等操作。比如你想把一个任务在5天内等间隔执行8次，可以直接算出每次间隔的timedelta再逐次累加，非常方便。这种"时间即对象"的设计，让代码表达起来非常自然，几乎不需要写什么循环计算年月的逻辑。

3. 实操过程与核心环节实现

3.1 常见时间处理场景完整示例

理论讲再多，不如实操来几发。我挑三个日常开发里出现频率极高的场景，给你完整跑一遍。第一个场景是处理日志文件的时间戳，把"2024-05-20 13:14:00,123"这种带逗号毫秒的字符串解析成时间对象，再转成另一种格式输出。这个场景在日志分析、数据清洗时太常见了，因为Python的logging模块默认输出的毫秒分隔符是逗号，而不是小数点。你要是直接拿%f去解析，百分百报错。正确姿势是这样：

from datetime import datetime log_time_str = "2024-05-20 13:14:00,123" log_dt = datetime.strptime(log_time_str, "%Y-%m-%d %H:%M:%S,%f") print("解析成功:", log_dt) # 输出: 2024-05-20 13:14:00.123000 # 转成带时区偏移的ISO格式 print(log_dt.isoformat()) # 输出: 2024-05-20T13:14:00.123000

第二个场景是计算"今天是今年的第几周"，这在做周报、排班系统、活动周期判断时很常用。需要注意%U和%W的细微差别：%U以周日作为一周的开始，%W以周一作为一周的开始。如果你用的是ISO标准，更推荐用date.isocalendar()方法，它返回一个包含ISO年份、ISO周数、ISO星期几的元组，而且不会出现"元旦属于上一年的第53周"这类会让业务方困惑的问题。

第三个场景是日期加减后重新格式化。比如财务系统里经常要生成"上个月同一天"的日期，或者"下个季度的第一天"。直接对月份做加减是不行的，因为月份天数不同，容易造成溢出（比如1月31日加一个月，2月没有31日，Python会抛ValueError）。我的处理方式是：优先用timedelta对天做加减，比如"30天前""90天后"这种；如果一定要跨月，那就先定位到目标月的第一天，再做一些偏移修正。这套思路虽然绕一点，但非常稳，不会因为月末、闰年这些问题翻车。

3.2 时区处理从入门到实践

时区是时间处理里水最深的部分，稍不留神就会出Bug，而且这种Bug特别恶心——平时测不出问题，一到夏令时切换或者跨时区调度就冒出来。Python处理时区，老一代的方案是pytz库，新一代的方案是标准库自带的zoneinfo模块（Python 3.9及以上可用）。我在新项目里一般直接用zoneinfo，依赖更少，而且跟官方推荐方向一致。

带时区的时间对象，最简单的创建方式是：

from datetime import datetime, timezone, timedelta from zoneinfo import ZoneInfo # 获取当前UTC时间（带时区信息） utc_now = datetime.now(timezone.utc) # 获取指定时区的当前时间 shanghai_tz = ZoneInfo("Asia/Shanghai") shanghai_now = datetime.now(shanghai_tz) # 时区转换：从UTC转上海时间 shanghai_time = utc_now.astimezone(shanghai_tz) print("UTC时间:", utc_now) print("上海时间:", shanghai_time) # 手动构造带指定偏移的时间对象，比如东八区 cn_tz = timezone(timedelta(hours=8)) cn_now = datetime.now(cn_tz)

这里有几个必须记住的原则。第一，业务存储建议统一用UTC时间，展示层再做本地时区转换，这样数据库里不会出现一堆来源不同、时区混乱的时间。第二，datetime.now()不带参数时返回的是"naive"（无时区信息）的本地时间，它与datetime.now(timezone.utc)相差的正是本地时区偏移。在做跨时区比较时，naive和aware对象不能直接比较，否则会抛TypeError。第三，夏令时问题：zoneinfo能自动识别夏令时规则，但前提是系统里有相应的时区数据库，在Windows上偶尔会缺少某些时区定义，这时用pytz兜底会更稳妥。搞时区，心里一定要有时区规范这根弦。

3.3 数据清洗与业务计算中的时间技巧

实际做数据分析或业务开发时，时间字段经常不是整整齐齐的标准格式。有可能是"2024/05/20"，有可能是"20-May-2024"，还有可能是纯数字"20240520131400"。面对这些乱七八糟的格式，我的建议是写一个通用的解析函数，把能想到的格式都列进去，依次尝试strptime解析。这比到处复制粘贴解析代码强得多。

还有一个高频需求是：判断某个日期是否在指定范围内。比如营销活动时间是2024年5月1日到5月5日，需要判断当前时间是否命中。最朴素的写法就是两个比较运算：

from datetime import datetime start = datetime(2024, 5, 1, 0, 0, 0) end = datetime(2024, 5, 5, 23, 59, 59) now = datetime.now() if start <= now <= end: print("活动进行中") else: print("活动未开始或已结束")

这种链式比较在Python里是合法的，而且可读性极好。如果要做更精细的窗口判断（比如"每分钟的前10秒内"），其实就是把时间粒度拆到秒或微秒再做区间判断，逻辑是相通的。

再分享一个数据聚合时的小技巧：按天、按小时分组统计。你不需要自己写复杂的字符串切割逻辑，可以直接用时间对象的date()方法提取日期部分，或者用replace(minute=0, second=0, microsecond=0)把时间对齐到小时。这些基础操作组合起来，能覆盖绝大多数业务报表的需求。

4. 常见问题与排查技巧实录

4.1 典型报错场景与解决方案速查表

写代码踩坑不可怕，可怕的是同样的坑踩第二次。我把遇到过的高频报错整理成一个速查表，方便你遇到问题时快速定位：

这里我特别想展开说一下时区比较那个报错。它在实际项目里出现的概率极高，尤其是当你从数据库取出一个datetime字段，跟datetime.now()做比较的时候。数据库驱动返回的往往是naive对象，而datetime.now(timezone.utc)返回的是aware对象，两者直接一比较就炸。我现在的习惯是：项目入口处就统一约定"所有内部时间都是aware UTC时间"，除非明确表示要展示给用户看时，才转成当地时区。这样约定之后，时区类型错误基本绝迹了。建议你在自己团队或项目里也立下这么一条规范。

4.2 时区夏令时与性能优化心得

夏令时是我最想吐槽的"坑中之坑"。如果你只处理中国时区，那还好，中国从1991年后就不再实行夏令时了，东八区一年到头偏移固定是+08:00。但如果你处理的是欧美业务，夏令时切换那几天，时间就会变得非常诡异——比如美国东部时间，春季某天凌晨2点直接跳到3点，那一天只有23小时；秋季某天凌晨1点又重复一遍，那一天有25小时。这种"重复"和"缺失"的时间，如果你用简单的timedelta加减去推算，得到的结果可能不是真实时间。zoneinfo能正确应对这些规则，但你依然要心里有数，在涉及跨夏令时的场景时，尽量用真实时区而不是手工偏移。

性能方面，datetime对象本身很轻量，绝大多数业务场景不需要额外优化。但如果你在大规模数据清洗中反复调用strptime解析海量时间字符串，性能问题就会浮现出来。一个很有效的优化是：针对性解析代替通用解析，比如直接用datetime(year, month, day, ...)构造，或者用切片、map(int, string.split(...))的方式快速拆分。我测试过，在几百万行日志的清洗任务里，这种方式比strptime快出好几倍。原因是strptime内部需要做格式串的解析和匹配，开销比较大。当然，代码可读性优先的场合，我还是推荐直接用strptime，毕竟性能瓶颈通常不在时间解析这一环。

4.3 跨平台与Python版本兼容性要点

Python的版本迭代很快，datetime相关的API也在不断进化。比如fromisoformat在Python 3.7之前只支持特定格式，到了3.11之后才支持更多ISO 8601变体；zoneinfo是Python 3.9才加入标准库的。如果你维护的项目要兼容老版本Python，就得格外小心这些API的可用性。

跨平台方面，最典型的是Windows和Linux在时区名称上的差异。Linux上，ZoneInfo("Asia/Shanghai")这种IANA时区名是通用的；但Windows上如果缺少时区数据库，你可能得用pytz，或者手动把Windows时区名转换成IANA名再传入。这个问题在容器化部署（比如Docker）时尤其容易现形——因为Docker基础镜像默认时区经常是UTC，而你本地机器可能是东八区。所以容器里跑定时任务时，一定要在Dockerfile里显式设置时区，或者在Python代码里用带时区的时间对象，否则就会出现"明明调度器配置的是每天8点，结果日志显示凌晨0点执行了"这种玄学问题。

我还有个习惯，就是给项目加一个自定义的时间工具模块，把now()、today()、parse_date()、format_datetime()这些常用操作统一封装，全部返回或接收带时区的对象。这样既方便代码复用，也避免每个人在各自代码里定义一套时间格式常量，最后格式五花八门，维护起来头大。

5. 完整实战：打造一个可复用的时间工具类

5.1 工具类的设计思路与完整代码

写到这里，理论知识说得差不多了。接下来我把自己项目里沉淀出来的一套时间工具类贴出来，给你做个参考。这个类解决了我日常开发中90%以上的时间处理需求，包括获取当前时间、字符串解析、格式转换、时区转换、时间差计算等。它的设计原则很简单：对外接口统一、内部处理时区标准化、解析逻辑能容错。

from datetime import datetime, date, timedelta, timezone from zoneinfo import ZoneInfo from typing import Optional, Union # 默认业务时区，可按项目需要调整 DEFAULT_TZ = ZoneInfo("Asia/Shanghai") UTC_TZ = timezone.utc class TimeUtil: """统一的时间处理工具类""" # 常用格式常量，避免散落各处 FORMAT_DATETIME = "%Y-%m-%d %H:%M:%S" FORMAT_DATETIME_MS = "%Y-%m-%d %H:%M:%S.%f" FORMAT_DATE = "%Y-%m-%d" FORMAT_COMPACT = "%Y%m%d%H%M%S" @classmethod def now(cls, tz: Optional[ZoneInfo] = None) -> datetime: """获取当前时间，默认返回业务时区时间""" return datetime.now(tz or DEFAULT_TZ) @classmethod def utc_now(cls) -> datetime: """获取当前UTC时间，始终带时区信息""" return datetime.now(UTC_TZ) @classmethod def parse(cls, time_str: str, fmt: Optional[str] = None) -> datetime: """ 解析时间字符串，支持显式格式和自动识别常见格式 """ if fmt: return datetime.strptime(time_str, fmt) # 自动解析支持的常见格式 for candidate in [ "%Y-%m-%d %H:%M:%S.%f", "%Y-%m-%d %H:%M:%S", "%Y/%m/%d %H:%M:%S", "%Y-%m-%d", "%Y/%m/%d", ]: try: return datetime.strptime(time_str, candidate) except ValueError: continue raise ValueError(f"无法解析时间字符串: {time_str}") @classmethod def format(cls, dt: datetime, fmt: str = FORMAT_DATETIME) -> str: """格式化时间对象为字符串""" return dt.strftime(fmt) @classmethod def to_tz(cls, dt: datetime, tz: ZoneInfo) -> datetime: """将时间对象转换到目标时区""" if dt.tzinfo is None: # naive对象默认视为UTC时间，避免猜测本地时区 dt = dt.replace(tzinfo=UTC_TZ) return dt.astimezone(tz) @classmethod def to_utc(cls, dt: datetime) -> datetime: """将任意时间对象转为UTC时间""" return cls.to_tz(dt, UTC_TZ) @classmethod def days_between(cls, dt1: datetime, dt2: datetime) -> int: """计算两个时间之间相差的天数（绝对值）""" if dt1.tzinfo is None: dt1 = dt1.replace(tzinfo=DEFAULT_TZ) if dt2.tzinfo is None: dt2 = dt2.replace(tzinfo=DEFAULT_TZ) return abs((dt1 - dt2).days)

使用的时候非常简单，比如TimeUtil.now()直接拿到带业务时区的当前时间，TimeUtil.parse("2024-05-20 13:14:00")快速解析字符串，TimeUtil.format(TimeUtil.utc_now(), TimeUtil.FORMAT_COMPACT)输出紧凑时间戳。你会发现，这套封装最大的好处是把"约定"固化成了"代码"——全项目统一用带时区的对象，统一格式常量，不会再出现"我这边是 UTC 的，你那边是东八区的，到底以谁为准"这种争论。

5.2 工具类的扩展思路与实现要领

这个工具类还有很大的扩展空间，我建议你根据自己项目的实际需求往里面加方法。比如加一个get_month_range方法，返回指定日期所在月份的第一天和最后一天，这在做月度报表时非常有用。再比如加一个get_week_range方法，返回周一和周日，方便做周报统计。还可以加一个humanize方法，把时间差转成"3天前""2小时前"这种人类友好描述，这在前端展示时很常用。

实现这些扩展方法时，保持一个原则：所有方法内部都把时间规整为带时区的时间对象再运算，避免mixed naive/aware带来的混乱。另外，方法返回类型要明确，别一会儿返回字符串，一会儿返回datetime对象，让调用方一头雾水。你要是把工具类维护好了，整个项目的时间处理代码会变得干净到不像话，新同事接手时也不用一遍遍问"这个时间是哪个时区的"。

6. 数据分析与量化场景的扩展思考

6.1 数据处理中的时间窗口计算

如果你做数据分析或者量化交易，时间处理的需求会更刁钻一点。量化里最经典的时间窗口计算是K线聚合：比如把每秒的行情数据聚合成1分钟K线、5分钟K线、1小时K线。这种需求的关键就是时间对齐。拿1分钟K线来说，你需要把每个时间戳对齐到它所属的那一分钟的起点。做法很简单：

from datetime import datetime # 假设 dt 是某一笔成交的时间 dt = datetime(2024, 5, 20, 13, 14, 35, 123456) # 对齐到分钟起点 minute_start = dt.replace(second=0, microsecond=0) print(minute_start) # 2024-05-20 13:14:00

如果是5分钟K线，不能直接replace，需要做一点运算：

import math def align_to_minute_interval(dt: datetime, interval_minutes: int = 5) -> datetime: """将时间对齐到指定分钟周期的起点""" minutes_since_midnight = dt.hour * 60 + dt.minute aligned_minutes = (minutes_since_midnight // interval_minutes) * interval_minutes return dt.replace(hour=aligned_minutes // 60, minute=aligned_minutes % 60, second=0, microsecond=0) dt = datetime(2024, 5, 20, 13, 14, 35) print(align_to_minute_interval(dt, 5)) # 2024-05-20 13:10:00

这个思路本质上就是用整除把时间戳"归位"到它所属的窗口。你换成小时、天、周都能用同一个套路。别小看这个操作，它是很多技术指标计算的基础，如果你聚合的时间窗口错位了，后面算出来的均线、MACD全会偏。

6.2 历史回测与绩效计算的时间对齐

量化回测里还有一个更棘手的问题：不同数据源的时间戳精度可能不一致。有的数据源精确到秒，有的精确到毫秒，还有的带时区偏移。如果你在做历史回测时把这几种数据直接混用，会出现订单成交时间晚于K线结束时间的鬼情况，回测结果自然不可信。

我的建议是，在数据接入阶段就统一做一次时间标准化：全部转成带时区的UTC时间，精度统一到毫秒，对齐到K线周期。这个预处理做扎实了，后面所有计算都省心。你可以在工具类里专门加一个normalize_timestamp方法，把各种奇葩输入（字符串、时间戳、datetime对象）全部归一化成统一的datetime对象，再统一输出。这种"统一入口、统一出口"的设计理念，在处理时间问题时永远适用。

7. 实用技巧与个人经验补充

7.1 项目日志与定时任务中的时间规范

日志是时间处理里最容易被忽略又最影响排查效率的地方。我现在给自己定的规则是：所有日志输出必须包含统一的、带时区的时间前缀，格式固定为YYYY-MM-DD HH:MM:SS.mmm，微秒保留三位（毫秒级）就够了，太多反而是噪音。这时可以用datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f")[:-3]来截断微秒字段，或者直接用datetime.now().astimezone().isoformat(timespec="milliseconds")。这种细节看起来不起眼，但在排查线上问题时，多一个 "Z" 后缀或者少一个毫秒位数，都可能导致你对着日志发呆半小时。

定时任务（比如APScheduler、cron、Celery beat）里的时间配置也容易出问题。配置里写的 "每天8点" 到底是谁的8点？如果是服务器本地时区，那换一台部署在不同地区的服务器，执行时间就可能对不上了。我的习惯是：定时任务的执行时间统一用业务时区描述，在代码里显式转成UTC时间后再调度，这样不管服务器部署在哪里，用户看到的时间都是一致的。

7.2 常用工具包推荐与选型对比

除了标准库，Python生态里还有几个处理时间的利器，我很推荐你在合适场景下选用。dateutil是个老牌第三方库，它的parser.parse()能自动识别超多种时间字符串格式，比手写格式串灵活太多，适合解析用户输入或外部系统传来的不规整数据。pendulum是个更加现代的库，API设计更友好，链式调用做时间加减非常舒服，内置了人性化的时间差表示（比如"3 days ago"）。arrow曾经也很火，但这两年维护节奏明显慢了下来，我建议新项目慎用。

选型的建议是这样：标准库能搞定的，优先标准库，毕竟少一个依赖就少一分维护成本；需要解析不规则时间字符串时，引入dateutil；需要同时处理多个时区且大量做时间运算的，可以考虑pendulum。千万别图省事把一堆时间库都引进来，每个库的时区处理逻辑略有差异，混用后容易互相打架，反而引入新的Bug。

7.3 我踩过的坑：时间字段存数据库的教训

最后讲一个我印象深刻的真实事故。早年我做一个预约系统，数据库字段用的是DATETIME，写入时直接用datetime.now()（naive本地时间）。后来服务器从国内迁移到海外，系统时间自动变成了UTC，新写入的预约时间跟老数据足足差了8个小时。用户一觉醒来发现自己预约的课程时间全乱了，那次事故真是让人头秃。从那以后，我所有的项目中，时间字段一律存UTC时间，应用层再根据用户时区转成本地时间展示。这样一来，数据本身没有任何歧义，不管以后服务器怎么迁移、用户在哪，都能正确还原时间。

还有一个教训是关于时间精度的。金融类系统里，时间精度就是钱，处理到微秒都不为过；但大部分业务系统里，微秒纯粹是数据库存储空间的浪费。在写入数据库之前，用replace(microsecond=0)手动去掉微秒，能省下不少空间，也让数据看起来干净。这个细节虽然小，在实际项目中却能减少很多困扰。

8. 最后的建议

datetime库其实没有多高深，核心就那几个对象和几组方法。但真正把时间处理做好，靠的不是背API，而是建立起一套清晰的规范和意识。比如：明确全项目统一用带时区的时间对象、统一一种存储格式（UTC）、统一格式常量、把高频操作封装成工具函数。这些规范一旦落地，你在时间处理上踩的坑会少掉七八成。我从实战中真切体会到，时间处理这门手艺，拼的不是聪明，而是细致和一致性。希望这篇文章里的经验和方法，能帮你少走一些弯路，把时间处理这个"看似简单实则容易翻车"的环节，稳稳拿捏住。