起步

这是一个架构权衡的问题。它不是从性能上去考虑的。时间戳到日期的互转只是简单的计算,消耗的计算量远远达不到其他地方。Mysql 内置了 timestampdatetime 两个类型供开发者选择。

这种类型要选哪个比较合适?这个时候首先要问自己,是不是要保存 1970 年以前的时间,如果是,那么就必须采用 datetime 了,没有其他选择。

这点以外,我更喜欢用时间戳,因为它能避免很多日期类型带来的问题。

日期时区问题

若应用涉及了多时区,那么保存日期格式会很麻烦,单单时区的设置就有操作系统设置的时区、后端语言设置的时区、数据库设置的时区。这转换关系足可以绕晕开发者,如果应用还是分布式多服务器的,那简直是爆炸啊。

保存时间戳则不会有这个问题,在世界任何时区里同一时间取得时间戳都是相同的,显示的时候也就多一个转换而已,绝对的物超所值。

日期格式不统一

01-01-2020 说不清是月在前还是日在前。有的开发者喜欢用 / 做分隔符。不过这点一般有统一的开发文档就不会成为问题。

麻烦的是如果前端要求显示 Y年m月d日 的形式呢,那后台就得日期->时间戳->日期,反而不如一开始就存时间戳。

日期是会变的

这点其实很奇葩,概率很低,主要是人为的修改时区,比如 委内瑞拉:时间在2007年12月9日倒退30分钟,见新闻: https://www.timeanddate.com/news/time/venezuela-enters-half-hour-zone.html ,大致是说委内瑞拉从时区是UTC-4小时改为了UTC-5小时。

尽管这种事非常少见,但至少说明了日期时间是会发生变化的。

日期格式不利于升级

Mysql 5.6 的 datetime 允许保存 0000-00-00 的数据,但在 5.7 则不允许,这种情况下旧数据就不好迁移到新环境了。

时间戳应选用 bigint

mysql 的 timestamp 用的还是 4 个字节存储,因此它会有 2038年问题 ,对此mysql官方还没给出解决方案,新方案如果是在新版本中解决的,那么对于无法升级的应该也是个灾难。

总结

时间戳是存时间的首选,但 datetime 也是未来的一个趋势,在 Django 应用中我还是很乐意用日期类型的,Django 很好的解决了时区的问题。相信在不久的未来,会有越来越完善的第三方组件帮助开发者解决时区问题后,datetime 也会越来越多的人使用。


本文由 hongweipeng 创作,采用 署名-非商业性使用-相同方式共享 3.0,可自由转载、引用,但需署名作者且注明文章出处。

赏个馒头吧