博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
数据库存储时间的时区问题
阅读量:6998 次
发布时间:2019-06-27

本文共 1021 字,大约阅读时间需要 3 分钟。

先说一下mysql中DATETIME和TIMESTAMP的区别

TIMESTAMP是标准的unix timestamp,它存储的是1970-1-1到现在经过的秒数,4字节存储。mysql用这个类型还蛮方便的,一个是有很多内置的函数和trigger来处理它,比如CURRENT_TIMESTAMP宏,最关键的是在取数据的时候mysql会自动帮你处理DST和时区的问题。

DATETIME的范围更大,好像可以从0000-00-00 00:00:00到9999-12-31 23:59:59,8字节存储,当然mysql内部肯定也是用整数而不是字符串的(说了是8字节了),所以效率不是大问题。但DATETIME不带时区,比如我在程序里生成了一个2015-05-07 15:26:00的时间(实际上是+8时区的,但这个对象可能是timezone naive)的,存到mysql里,再从不同时区的地方拿出来,这个时间可能就混了。

但TIMESTAMP也有两个很大的问题:

  1. 4字节长度限制,它只能到2038年
  2. 很多时候我们希望根据用户所在地的时区显示时间而不是光显示一个服务器时间

所以比较好的做法是,数据库中使用DATETIME,然后存时间的时候一律用程序生成UTC时间(而不是local时区的时间)存进去,取出来的时候不管想显示服务器时间还是显示用户的时间都可以处理。

顺便提一句,根据用户所在地时区显示时间有两种做法:

  1. 当用户第一次访问网站的时候,用js获取时区发送到服务器上存到session里
  2. 用js处理时间的显示(我觉得这种比较方便一点,毕竟不用改服务端代码)

使用这种做法的唯一缺点是sqlite3没有internal的DATETIME类型,所以在ORM框架如sqlalchemy中,它会直接存字符串进去。(sqlite3的文档也说,你要么存成int要么real要么字符串)。尽管这可能带来一些不方便和性能的下降,但我认为还是符合“keep it simple and stupid”的原则。

至于用INT存时间,是另一种可行的方法,参见

我个人不是很喜欢这么做,因为这样你必须把模型中表示时间的成员声明为int类型。这样是比较不符合逻辑的(那些Date呀Datetime之类的类就没有用了呀,最多就有个Dateutil就好了),而且会使得程序不易读(卧槽这个publishedDate为什么是int,它到底表示的是时间吗?)。总之见仁见智。

转载地址:http://ordvl.baihongyu.com/

你可能感兴趣的文章
cookie localstorage sessionStorage
查看>>
某数加密的流程与原理简析
查看>>
《前端十年心路》书稿规划
查看>>
Java虚拟机规范(目录)
查看>>
4.java数组
查看>>
阿里开发者们的第19个感悟:Simple is better.
查看>>
区块链技术进阶
查看>>
超简单七步,解决windows下安装PaddlePaddle的权限错误!
查看>>
Appium框架
查看>>
微信小程序教程系列之设置标题栏和导航栏
查看>>
Jenkins 用户文档(入门)
查看>>
轻松检测Golang并发的数据竞争
查看>>
如何处理错误消息Please install the gcc make perl packages
查看>>
写完这段代码,就被开除了……
查看>>
浅析微信支付:如何使用沙箱环境测试
查看>>
分布式系统关注点——仅需这一篇,吃透「负载均衡」
查看>>
实现文字的省略号
查看>>
react 移动端 兼容性问题和一些小细节
查看>>
人工智能的时代来了,新的商业机会在哪里?
查看>>
ZooKeeper 文档(概述)
查看>>