在Django中将Unix时间戳存为整数，按需转datetime是否为不良实践？

其实这不能一概而论，得看你的具体场景——但绝大多数业务场景下，直接用Django原生的DateTimeField会是更稳妥的选择，用IntegerField存Unix时间戳确实属于非最佳实践，下面具体聊聊原因和你提到的几个方案：

为什么不推荐用IntegerField存时间戳？ #

• 丢掉数据库原生的时间能力：数据库的datetime类型自带范围查询、排序、时区转换等原生功能，比如你想查「近7天的数据」，用DateTimeField直接写created_at__gte=one_week_ago就行；但如果存成整数，你得先把时间转成戳再写查询，不仅麻烦，还可能让数据库索引的优化效果打折扣。
• 可读性极差：盯着数据库里一串数字，没人能立刻反应过来这是哪天哪时，调试或直接操作数据库时，排查问题会特别费劲。
• 时区bug隐患：Unix时间戳本身是UTC标准，但手动转换时很容易忽略时区处理，比如把本地时间的戳当成UTC存，导致时间偏移。而原生DateTimeField配合Django的时区设置，能自动帮你处理这些细节。

关于你提到的几个替代方案 #

1. django-unixdatetimefield包 #

这个包的核心优势是帮你封装了时间戳和datetime的自动转换逻辑——你不用在代码里反复写datetime.fromtimestamp()或者obj.created_at.timestamp()，字段会自动处理入库（把datetime转成戳）和取数（把戳转回datetime）的过程，相当于给IntegerField套了一层DateTimeField的友好接口。但如果不是业务必须要存时间戳，原生DateTimeField还是更省心。

2. 重写DateTimeField的pre_save方法 #

真的没必要，属于过度设计。如果你的需求是接收前端传来的时间戳，完全可以在表单或序列化器层面处理转换：比如在DRF序列化器里写个自定义字段，把传入的时间戳转成datetime对象，再交给原生DateTimeField存储，这样既简单，又不会破坏原有字段的逻辑。

什么时候可以考虑用IntegerField存时间戳？ #

如果你的业务有特殊需求，比如：

• 需要和只支持Unix时间戳的第三方系统频繁对接，重复转换会带来性能损耗；
• 数据库本身不支持datetime类型（这种情况现在几乎见不到）；
• 你对存储空间有极致要求（整数比datetime占用空间略小，但现在数据库存储成本极低，这点优势基本可以忽略）。

这种场景下，用IntegerField存时间戳是可以接受的，但一定要封装自定义字段，统一处理转换逻辑，别让转换代码散落在项目各个角落。

内容的提问来源于stack exchange，提问作者Aran Freel