数据库存储时间的时区问题

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

TIMESTAMP是正规的unix
timestamp,它存款和储蓄的是一九六八-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不带时区,比方作者在前后相继里生成了三个2016-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存时间,是另一种有效的诀要,参见http://www.liaoxuefeng.com/article/0014132675721847f569c3514034f099477…
自己个人不是很欣赏那样做,因为如此你必需把模型中象征时间的成员声称为int类型。那样是相比较不合乎逻辑的(那多少个Date呀Datetime之类的类就一直不用了啊,最多就有个Dateutil就好了),况且会使得程序不易读(卧槽那几个publishedDate缘何是int,它到底意味着的是光阴吧?)。同理可得见仁见智。

Post Author: admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注