我至今记得第一次用datetime处理订单时间，因为时区问题被客户投诉的尴尬经历。很多新手在处理时间数据时都会遇到显示混乱、计算错误的问题，今天我们就来拆解这个看似简单实则暗藏玄机的数据类型。

datetime和timestamp到底有什么区别？
刚入门时我也分不清这两个概念。简单来说，timestamp是计算机存储的时间戳（一串数字），而datetime是人类可读的日期时间格式。比如订单创建时间用datetime显示"2024-07-20 15:30"，但数据库实际存储的是类似1721475000这样的时间戳。

创建datetime对象的3种正确姿势
1. 直接声明：from datetime import datetime
now = datetime.now()
2. 指定时间：order_time = datetime(2024,7,20,15,30)
3. 解析字符串：datetime.strptime("2024-07-20", "%Y-%m-%d")

90%的时间错误都出在这里的时区处理
上周帮学弟调试程序，发现他直接把服务器时间显示给用户，导致海外用户看到的时间全部错乱。记住三个要点：
- 服务器必须使用UTC时间
- 前端根据用户时区转换显示
- 用pytz库处理时区转换
示例代码：
python from pytz import timezone local_time = utc_time.astimezone(timezone('Asia/Shanghai'))

时间计算的三大陷阱
1. 闰年判断：直接使用calendar模块的isleap方法
2. 跨月计算：用dateutil的relativedelta代替普通加减
3. 夏令时处理：永远不要手动计算，必须使用时区库

当需要计算30天后的日期时，错误的写法：
datetime.now() + timedelta(days=30)
正确的写法：
from dateutil.relativedelta import relativedelta
datetime.now() + relativedelta(months=1)

格式化输出的万能公式
见过有人用字符串拼接年月日，结果在跨年时出现显示错误。强烈建议使用标准格式化符号：
- %Y 四位年份（2024）
- %m 补零月份（07）
- %d 补零日期（05）
- %H 24小时制小时
最安全的写法：
datetime.strftime("%Y-%m-%dT%H:%M:%S%z")

个人建议：处理时间数据要比处理金钱更谨慎。曾经因为忘记处理毫秒精度，导致两个订单被判定为同时创建引发系统异常。推荐使用arrow库替代原生datetime，它的链式调用和智能解析能减少80%的代码量。记住，每一个时间错误背后都可能站着愤怒的用户和真金白银的损失，这个数据类型值得我们花三天时间彻底吃透。