Python日期时间处理：核心对象、格式化与时区避坑指南

Python处理日期和时间，几乎是每个写脚本的人都会撞上的事。我自己带过不少入门的朋友，发现大家一旦开始写爬虫、处理日志、做数据清洗，第一个懵掉的地方往往不是语法，而是datetime这个模块到底该怎么用。网上搜"python日期"能搜出一堆零散代码，但真正能把date、time、datetime、timedelta这四个对象分清楚、知道什么时候该用哪个的人，其实不多。这篇就按我实际写项目时的思路，把日期时间处理的常见场景、常见坑和可直接抄作业的写法一次讲透。

这篇内容适合刚学Python不久、正在写爬虫或数据处理脚本的读者，也适合写过一段时间但总在格式化、时区、日期加减上翻车的朋友。读完你能自己处理日志里带毫秒的时间戳、生成带日期的文件夹名、把Oracle里的毫秒数转换成可读日期、跨时区转换时间，并且理解为什么你的代码里日期总差一天或者格式总对不上。

1. 先搞懂datetime的四个核心对象，后面才不迷糊

很多初学教程喜欢一上来就甩一堆代码，但这会让大部分人越看越乱。我的经验是，先花十分钟把datetime模块里四个最常用的对象搞清楚，后面所有操作都会变得非常顺。

1.1 date：只装年月日的"日历小方块"

datetime.date是三者里最轻量的一个，它只关心年、月、日，跟时分秒完全没关系。比如你只想记录今天是哪一天、判断两个日期相差多少天，或者从数据库里读出一个YYYY-MM-DD的字段，直接用date就够了。

from datetime import date today = date.today() print(today) # 2026-03-18 print(today.year) # 2026 print(today.month) # 3 print(today.day) # 18 # 也可以手动构造一个日期，注意参数顺序是年、月、日 appointment = date(2026, 12, 31) print(appointment.weekday()) # 3，表示星期四，周一是0

这里有个容易忽略的点：date对象是不可变的，你没法直接改它的.month或者.year。想改日期，要么用replace()返回一个新对象，要么用timedelta做加减。所以别想着today.day = 19，这样会直接报错，相信我，这错误我见过太多次了。

1.2 time：只管时分秒和微秒的小钟表

datetime.time负责存一天中的时间，比如 14:30:25。它不关心是哪一天，只关心钟表指针指到哪。它甚至可以精确到微秒，这也是为什么你打印datetime.now()时，经常看到一长串小数。

from datetime import time t = time(14, 30, 25, 123456) print(t) # 14:30:25.123456 print(t.hour) # 14 print(t.minute) # 30 # 比较两个时间谁早谁晚 t1 = time(9, 0) t2 = time(18, 0) print(t1 < t2) # True，9点早于18点

但实际业务里，单独用time的场景其实不算多，大多时候我们是用完整的datetime。只有一个例外：你只关心每秒的耗时、只整理某个时刻的排班表，不想牵扯日期，那time才比较合适。

1.3 datetime：四位一体的完整时刻

datetime.datetime是最常用的对象，它把日期和时间都装在一起。创建当前时刻用datetime.now()，获取UTC当前时间用datetime.now(timezone.utc)，这俩区别以后说时区的时候重点讲。

from datetime import datetime now = datetime.now() print(now) # 2026-03-18 14:30:25.123456 # 手动指定时间和日期 dt = datetime(2026, 3, 18, 14, 30, 25) print(dt)

这一下就很直观了：一个datetime对象，你既可以访问.year、.month，也可以访问.hour、.second，是前两个对象的合体。从date和time组合出datetime也很方便：

d = date(2026, 3, 18) t = time(14, 30) full = datetime.combine(d, t) print(full) # 2026-03-18 14:30:00

反过来，从datetime里取date或time部分也是常用操作：

now = datetime.now() print(now.date()) # 2026-03-18 print(now.time()) # 14:30:25.123456

这种互相转换在写接口对接、操作数据库字段时几乎是每天都要干的活。

1.4 timedelta：处理时间差的万能尺子

timedelta表示的是两个时间点之间的差，比如相差多少天、多少秒。它最大的用处是帮我们做日期加减，比如"7天后的提醒"、"3小时后的过期时间"。

from datetime import datetime, timedelta now = datetime.now() one_week_later = now + timedelta(days=7) print(one_week_later) # 也可以加小时、分钟、秒，甚至是微秒 two_hours_later = now + timedelta(hours=2) half_day_before = now - timedelta(days=1, hours=12)

要注意的是，timedelta没有"月"和"年"的参数。为什么？因为月有28天也有31天，年有365天也有366天，一个固定的差值没法代表一个月。想加一个月，得自己写逻辑，这里先记住这个结论，后面专门展开。

理解了这四个对象之后，你会发现网上一堆报错其实都源于同一个问题：拿datetime去减date，或者拿time去和datetime比较，类型不匹配，自然崩。

2. 格式化与解析：字符串和日期互转的核心细节

日期和字符串的互转，是新手问得最多、出问题也最多的环节。一个来自日志接口的2026-03-18 14:30:25.123，怎么读进Python？一个datetime对象怎么输出成2026年03月18日？这些都靠strptime和strftime，名字都源自C语言的函数风格。

2.1 strptime：把字符串解析成datetime对象

strptime的作用是字符串到对象，第一个参数是原字符串，第二个参数是格式。关键是这个格式必须和你字符串的真实结构完全一致，一个字符都不能差。

from datetime import datetime s = "2026-03-18 14:30:25" dt = datetime.strptime(s, "%Y-%m-%d %H:%M:%S") print(dt) # 2026-03-18 14:30:25

常见的格式代码，我列个表，方便随时查：

容易出问题的两类情况：一类是%m和%M搞混，前者是月份 month，后者是分钟 minute，大小写不同含义完全不同；另一类是时间格式里带毫秒但你没写%f，或者写了%f但字符串里只有三位毫秒，Python也会解析失败。

比如日志里常见的2026-03-18 14:30:25.123，这里的123通常是毫秒，而%f是6位微秒。别慌，Python的%f实际上可以解析1到6位数字，所以直接这样写就能用：

s = "2026-03-18 14:30:25.123" dt = datetime.strptime(s, "%Y-%m-%d %H:%M:%S.%f") print(dt) # 2026-03-18 14:30:25.123000

注意输出变成了末尾补零的微秒。如果业务里不关心微秒，建议在解析后就调用.replace(microsecond=0)清掉，这样后续输出更干净，也免去很多字符串对比时因为精度不同导致不相等的问题。

2.2 strftime：把datetime对象输出成自定义格式

strftime是对象到字符串，作用与strptime正好相反，用法却很像。

from datetime import datetime now = datetime.now() print(now.strftime("%Y-%m-%d %H:%M:%S")) # 输出：2026-03-18 14:30:25 print(now.strftime("%Y年%m月%d日 %H时%M分%S秒")) # 输出：2026年03月18日 14时30分25秒 print(now.strftime("%A, %B %d, %Y")) # 输出：Wednesday, March 18, 2026

%A和%B输出的是英文星期和月份名，因为它依赖系统的locale。你要是想输出"星期三"这种中文，要么手动映射，要么改locale。手动映射其实很简单：

weekdays = ["星期一", "星期二", "星期三", "星期四", "星期五", "星期六", "星期日"] print(weekdays[now.weekday()])

这里用weekday()返回的数字做索引，周一返回0，所以列表第一位是星期一。

2.3 时间戳和毫秒数的互转：吞掉一批报错的硬核操作

间隔侧重的是字符串和对象互转，但真实项目里还经常会遇到纯数字时间戳。尤其是对接Java系服务时，返回的时间经常是毫秒级时间戳，比如1773581425123，直接传给Python的datetime.fromtimestamp()会算出一个非常离谱的日期，因为那个函数默认接收的是秒。

from datetime import datetime # 秒级时间戳正常转换 ts = 1773581425 print(datetime.fromtimestamp(ts)) # 输出：2026-03-18 14:30:25（取决于本地时区） # 毫秒级时间戳必须除以1000 ts_ms = 1773581425123 print(datetime.fromtimestamp(ts_ms / 1000)) # 输出：2026-03-18 14:30:25.123000

这也是热搜里"oracle毫秒转换日期格式"、"fastjson时间转时间戳"对应的实际问题。Oracle数据库里存的时间戳经常是DATE转成毫秒数，Fastjson返回的JSON字段也常是毫秒时间戳。拿到这类数据时，记得先判断数字位数：13位基本就是毫秒，10位是秒，16位是微秒。

反过来，把datetime转成毫秒时间戳也有对应的写法：

now = datetime.now() # 先算从1970-01-01到当前的秒数，再乘以1000 ts_ms = int(now.timestamp() * 1000) print(ts_ms)

注意如果你的datetime对象是naive（无时区信息），timestamp()会按系统本地时区解释它。如果你操作的是UTC时间，最好先显式声明时区，否则打印出的时间戳可能和预想差8个小时。

2.4 Python 3.7+ 还能用 fromisoformat 省事

如果你拿到的字符串是ISO 8601标准格式，比如2026-03-18T14:30:25或2026-03-18T14:30:25+08:00，可以直接用datetime.fromisoformat()，不用手写格式串。

s = "2026-03-18T14:30:25+08:00" dt = datetime.fromisoformat(s) print(dt) # 2026-03-18 14:30:25+08:00

Python 3.11之后这个函数对更多变体格式的兼容性变强了，但为了稳妥，如果是老项目或者Python 3.9以下，还是建议用strptime手动匹配。省事和稳妥之间，得按你当前的Python版本做取舍。

3. 日期加减与比较：从"相减得到分秒"到"跨月不翻车"

日期加减是日常开发里最刚需的操作。你以为只是+timedelta(days=1)这么简单，真做起来会发现月份进位、天数不足、字符串比较这些坑都在等着你。

3.1 两个时间相减，怎么得到"天时分秒"

做过计时统计的都知道，两个datetime相减会得到一个timedelta，这个timedelta有.days、.seconds、.microseconds属性。注意它没有.hours，也没有.minutes。

from datetime import datetime start = datetime(2026, 3, 18, 9, 0, 0) end = datetime(2026, 3, 18, 14, 30, 25) diff = end - start print(diff) # 5:30:25 print(diff.days) # 0 print(diff.seconds) # 19825（即5小时30分25秒换算成的总秒数）

如果想显示成"X天X小时X分X秒"这种格式，需要自己手动拆：

days = diff.days seconds = diff.seconds hours = seconds // 3600 minutes = (seconds % 3600) // 60 secs = seconds % 60 print(f"{days}天{hours}小时{minutes}分{secs}秒") # 输出：0天5小时30分25秒

这里更容易踩坑的一个操作是：如果想得到总分钟数，很多人会写成diff.seconds // 60，但这样会丢掉整天的时间。正确写法是diff.total_seconds() // 60。

total_minutes = diff.total_seconds() // 60 print(total_minutes) # 330.0

total_seconds()会把天、小时、分钟、秒、微秒全部折算成秒，是最不容易算漏的方法。热搜里提到的"时间相减得到分秒"，本质就是这个：先total_seconds()，再除以60得到分钟，余数取整得到秒。

3.2 加减天数很简单，加减月份才是真正的考验

加天数、加周数、加小时，timedelta直接搞定：

from datetime import datetime, timedelta now = datetime.now() print(now + timedelta(days=30)) print(now + timedelta(weeks=2)) print(now + timedelta(hours=8))

但如果你要加一个月，比如从1月31号加一个月，理论上应该是2月28号或者29号，而不是Python自动进位到3月3号。timedelta没有月的参数，所以得自己写。最稳妥的写法是用replace配合calendar.monthrange判断目标月份有多少天。

from datetime import datetime from calendar import monthrange def add_months(source, months): month_index = source.month - 1 + months year = source.year + month_index // 12 month = month_index % 12 + 1 day = min(source.day, monthrange(year, month)[1]) return source.replace(year=year, month=month, day=day) print(add_months(datetime(2026, 1, 31), 1)) # 输出：2026-02-28 00:00:00

这个函数我一直在用，逻辑也不复杂：先粗暴地算目标年和月，再取目标月的最大天数跟原日期做min，避免日期溢出。减月份也一样，传入负数就行。

3.3 日期比较：别拿字符串硬刚

日期比较的场景很多，比如判断任务是否过期、判断某时间是否在某个范围内。datetime和date都支持直接比较：

from datetime import datetime deadline = datetime(2026, 3, 20, 18, 0, 0) now = datetime.now() if now < deadline: print("还没过期") else: print("已过期")

但有时候从接口拿到的是字符串"2026-03-20 18:00:00"，有人会图省事直接字符串比较。这里要特别提醒：字符串比较在格式统一、都是零填充时可能碰巧正确，但一旦出现单月无前导零、时区后缀、不同长度，结果就完全不可靠。正确做法是转换成datetime再比较。

s_deadline = "2026-03-20 18:00:00" s_now = "2026-03-18 14:30:00" deadline = datetime.strptime(s_deadline, "%Y-%m-%d %H:%M:%S") now = datetime.strptime(s_now, "%Y-%m-%d %H:%M:%S") print(now < deadline) # True

VBA里有DateDiff和DateSerial，Python里对应的是timedelta+ 构造函数。如果你从Excel VBA转过来，记住Python里没有DateDiff("d", d1, d2)这种现成函数，但(d2 - d1).days一行就能达到同样效果。

3.4 排序：列表里的日期排个序

日期排序经常会出现在统计报表、任务清单里。datetime对象天然可比较，所以直接sort()就能按时间先后排序。

from datetime import datetime date_strs = ["2026-03-18", "2026-02-01", "2026-12-31"] dates = [datetime.strptime(s, "%Y-%m-%d") for s in date_strs] dates.sort() print([d.strftime("%Y-%m-%d") for d in dates]) # 输出：['2026-02-01', '2026-03-18', '2026-12-31']

如果排序的是字符串且格式固定为YYYY-MM-DD，字符串排序偶尔也能用，但我还是建议养成先转对象再排序的习惯，防止某天格式里混进时分秒或时区。

4. 时区与时间戳：本地时间、UTC、数据库和爬虫的避坑要点

时区是日期处理里最容易出"灵异事件"的部分。很多人本地跑脚本一切正常，一到服务器上时间就错了8个小时；或者往数据库里写时间后，读出来发现差了一天。这些问题基本都和时区处理不规范有关。

4.1 naive和aware：一个看不见但致命的区别

datetime对象分两种：

• naive：没有时区信息，就像一个"裸"时间。
• aware：带时区信息，知道自己相对于UTC偏移多少。

from datetime import datetime, timezone naive_now = datetime.now() # 无时区信息 aware_now = datetime.now(timezone.utc) # 带UTC时区 print(naive_now.tzinfo) # None print(aware_now.tzinfo) # UTC

naive和aware不能直接比较，也不能直接做加减，否则会抛TypeError: can't compare offset-naive and offset-aware datetimes。这个报错很多人都见过。解决的思路很简单：要么全部转成aware，要么全部转成naive，别混着用。

4.2 本地时区：ZoneInfo比pytz更省心

Python 3.9之前，大家普遍用pytz；3.9之后标准库加入了zoneinfo.ZoneInfo，我现在基本只推荐这个，因为它是官方维护、不会出现pytz那种localize()的怪癖。

from datetime import datetime, timezone from zoneinfo import ZoneInfo # 表示"当前中国标准时间" now_cn = datetime.now(ZoneInfo("Asia/Shanghai")) print(now_cn) # 输出：2026-03-18 14:30:25+08:00 # 把中国时间转成UTC now_utc = now_cn.astimezone(timezone.utc) print(now_utc) # 输出：2026-03-18 06:30:25+00:00

astimezone是时区转换的核心方法。你只要有一个aware的datetime，想显示成东京时间、纽约时间、UTC时间，都是同一套操作，把目标ZoneInfo传进去就行。

4.3 爬虫和API对接时的时区坑

爬虫拿到的网页时间经常带时区后缀，比如2026-03-18T14:30:25+08:00。这类字符串最好的处理方式是解析成aware对象：

from datetime import datetime s = "2026-03-18T14:30:25+08:00" dt = datetime.fromisoformat(s) print(dt) # 2026-03-18 14:30:25+08:00 print(dt.utcoffset()) # 8:00:00

之后如果需要和UTC时间对比、或者入库，先统一转成UTC再存。我自己的习惯是：数据存储一律存UTC时间戳或UTC的datetime，只在界面展示时才转成当地时区。这么做能避免大量因部署地点变化导致的差8小时问题。

4.4 数据库中的时间写入：避免"本地时区"幻觉

用sqlite3或pymysql写时间时，常见错误是直接把naive的本地时间塞进去。要是之后服务器从中国迁到海外，本地时间就不是UTC+8了，老数据和新数据就对不上。更稳的方式是先把时间转成UTC：

from datetime import datetime, timezone now_utc = datetime.now(timezone.utc) # 入库时用这种带UTC时区的对象，或者统一存时间戳 int

如果你用的是Django，并且设置了USE_TZ = True，Django本身会强制你处理aware时间，写模板或ORM时都会自动转时区。问题大多出现在直连数据库的脚本里，那就要自己扛起这个责任。

4.5 时间服务器和系统时间：脚本跑在谁的钟上？

有些脚本会依赖系统时间，比如日志采集、定时任务判断。这里有个容易忽略的点：datetime.now()拿的是运行机器自己的本地时间，如果服务器的时区没设置对，或者系统时间被同步到了错误的时区，脚本拿到的本地时间就是错的。

反过来说，如果你在一个需要跨多台服务器协作的系统里，不要依赖各机器的本地时间做判断；要么全部用UTC，要么用时间同步后的统一时间基准。热搜里那些"时间服务器"、"查看电脑开机时间"的需求，本身并不复杂，但反映的是同一个问题：时间基准必须统一，否则所有日期逻辑都会失真。

5. 实战脚本：日志、爬虫、文件夹命名和时间序列的常用套路

理论讲得再多，也得落到具体场景里。这一节我直接按真实需求列出几个高频脚本套路，每个都能直接改一改用。

5.1 日志分析：从字符串里批量解析时间

日志文件里的时间格式五花八门。我处理最多的是两种：2026-03-18 14:30:25,123这种带逗号毫秒的，和2026-03-18T14:30:25.123456Z这种ISO格式带Z的。

import re from datetime import datetime log_line = "2026-03-18 14:30:25,123 ERROR something failed" match = re.search(r"(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}),(\d{3})", log_line) if match: dt = datetime.strptime(match.group(1), "%Y-%m-%d %H:%M:%S") # 手动补上毫秒 dt = dt.replace(microsecond=int(match.group(2)) * 1000) print(dt)

注意,123是毫秒，不能直接用%f解析，因为%f遇到3位会当微秒用，导致数值差了1000倍。这也是很多人在处理日志时莫名其妙多出3个0的原因。

如果日志里是带Z结尾的UTC时间，可以先把Z换成+00:00，再fromisoformat：

s = "2026-03-18T14:30:25.123456Z" normalized = s.replace("Z", "+00:00") dt = datetime.fromisoformat(normalized) print(dt)

5.2 爬虫：解析网页里的发布时间

爬虫里最常见的操作是抓取文章发布日期，而不同网站格式差距很大。比如有的给2026-03-18 14:30，有的给2026-03-18T14:30:25+08:00。一个比较省心的办法是写一个可兜底的解析函数：

from datetime import datetime def parse_date(value): if isinstance(value, datetime): return value value = value.strip() for fmt in ( "%Y-%m-%d %H:%M:%S", "%Y-%m-%d %H:%M", "%Y-%m-%d", "%Y/%m/%d", "%Y年%m月%d日", ): try: return datetime.strptime(value, fmt) except ValueError: continue # 最后尝试ISO格式 return datetime.fromisoformat(value.replace("Z", "+00:00")) print(parse_date("2026-03-18 14:30")) print(parse_date("2026年03月18日"))

这种兜底函数的价值在于：你不是每次都能控制数据源格式，多写几个try就能避免整个爬虫因为一条脏数据崩溃。

5.3 生成带日期的文件夹或文件名

营销系统导出报表、数据库备份、日志归档，都需要在文件名里带时间。这个需求我用得极多，代码也就三行：

from datetime import datetime now = datetime.now() folder_name = now.strftime("backup_%Y%m%d_%H%M%S") print(folder_name) # 输出：backup_20260318_143025

如果你的备份任务一天跑好几次，一定要把时分秒也带进去，否则同名文件会把前一次的覆盖掉。这个坑我在早期部署脚本时踩过，损失不大但很烦。

5.4 生成连续日期列表：时间序列的基石

做数据统计时，经常要生成某段范围内的所有日期。比如Kettle批量遍历日期查数、SQL报表按天补全，这类需求在Python里用循环加timedelta就能搞定：

from datetime import datetime, timedelta start = datetime(2026, 3, 1) end = datetime(2026, 3, 10) dates = [] current = start while current <= end: dates.append(current.strftime("%Y-%m-%d")) current += timedelta(days=1) print(dates) # 输出：['2026-03-01', '2026-03-02', ..., '2026-03-10']

如果数据量很大或者需要按小时、按分钟生成，可以用pandas.date_range，它更高效，但那是另一个话题了。上面的原生写法在常规范围内完全够用。

5.5 计算两个时间点之间的耗时并显示为"分秒"

这个场景在压测、接口耗时统计里非常常见。你记录一个请求开始时间和结束时间，然后想输出"耗时3分25秒"：

from datetime import datetime start = datetime.now() # ... 模拟一段耗时操作 ... end = datetime.now() delta = end - start total_seconds = int(delta.total_seconds()) minutes, seconds = divmod(total_seconds, 60) print(f"耗时 {minutes} 分 {seconds} 秒") # 输出：耗时 3 分 25 秒

divmod返回商和余数，专门用来做这种拆解，比手动求整除再取模干净不少。

6. 写了几年脚本，我总结的几个日期处理建议

这一节是纯个人经验，也是我被折腾得多了之后刻进骨子里的习惯。

第一，统一标准是最高优先级。我所有脚本里，只要涉及跨系统、跨服务器或持久化存储，一律以UTC为基准，展示时才转本地时间。这个习惯帮我避免了很多"为什么线上比线下差8小时"的排查。你也不用一开始就懂所有时区理论，先记住"存UTC、显本地"这句话就够了。

第二，解析字符串时别过度信任格式。外部数据源的格式随时会变，比如日志中间多了个空格、毫秒分隔符从逗号变成点。我在爬虫和日志解析里全部使用了带try的兜底函数，而不是一个strptime裸奔。宁可多写两次循环，也不要让整批任务因为一条脏数据中断。

第三，不要靠记忆写格式码。%Y和%y差一个字母、%m和%M差一个大小写，错了出来的结果非常迷惑。我至今写strptime时还会偶尔翻查格式表。特别是%f，它表示微秒而非毫秒，虽然能解析1到6位数字，但你要知道"3位毫秒"和"6位微秒"的区别，否则数值上会差1000倍。

第四，timedelta不能加月份，这是设计不是缺陷。如果你需要按月份做业务逻辑，直接写一个类似前面add_months的小工具函数放公共模块里，比每次临时算靠谱得多。

第五，环境一致性要提前检查。写好的脚本本地跑没问题，部署到服务器后日期处理出错的案例我见过不少。常见原因包括：服务器时区没配对、Python版本太低导致fromisoformat不可用、系统locale不是中文导致星期几输出变成英文。上线前花一分钟跑一下python --version和date命令，能省下大半天排查时间。

第六，不要沉迷于第三方库。arrow、dateutil、pendulum都很好，但在团队项目里，第三方库会增加维护成本。标准库的datetime加上zoneinfo，已经能覆盖我日常工作95%以上的需求。dateutil的parser.parse适合偶尔用的灵活解析场景，除此之外我尽量让自己少引入不必要的依赖。

最后再分享一个小技巧：如果你发现自己总在处理日期时频繁写try except，别怀疑是自己水平不够，往往是数据源太混乱。这时候最重要的不是优化解析代码，而是先和数据提供方明确时间字段的格式规范和时区口径。很多"灵异时间"问题，源头根本不在代码，而在上游数据。

日期时间处理不像算法那样炫酷，但它藏在每个系统的毛细血管里。把基础对象、格式化、加减、时区这四件事打通，Python里遇到时间相关的需求，你基本就能从容应对了。