我发现数据库有些日期居然用字符串保存？于是跟几个小伙伴讨论了关于数据库的日期应该要怎么保存的问题，其实我一直都建议直接用数值保存时间戳，为什么我要这么建议呢？

以下，我会从时区的概念来跟你们解释一下，为什么用数值保存时间戳是最好的方案，同时也为了分享出来，让更多开发小伙伴留意这些细节性的东西。

相信时区对于很多人来说的很熟悉，因为地球是圆的，在地球上不同角落看到的太阳上升的角度都是不同的，即每个人对于时间的显示都是不一样的，

举个例子：

此时处于东 8 区的我们北京时间是 10 点，那么处于东 1 区的时间就是 3 点，但是他们的时间是等价的：

"2019-06-20 10:00 +8:00" = "2019-06-20 3:00 +1:00"

所以说，对于不同时区的人来说，显示的时间是不一样的，那么此时你是如何将将时间保存到数据中的呢？

我姑且假设你用的是 new Date() 方法来保存当时日期，但据我所知道的，数据库的 DateTime 类型是没有时区信息的，如果你此时用 DateTime 格式保存日期，就会丢失时区信息，如果你的服务器更该地址，从数据库读出来的日期数据就是错误的！

可能你会说，那我用 timeStamp 类型保存总不会丢失时区信息了吧？确实没丢失，没毛病。但是据我所知道的，timeStamp 保存的时间最长不能超过 2037 年，而且你要考虑每个数据的 timeStamp 类型都有可能不一样。

至于用字符串来存储时间，就更加不推荐了，姑且不从时区来说，你比较日期大小也是个问题，我举个例子：

to_char(SYSDATE, '2019-06-01 00:00:00') > START_TIME

要比较一个时间大小，我需要这么做，还需要将系统时间转成字符串来给你对比，而且在转换成字符串比较时，数据库内部也会将其转换成时间来比较，你觉得这种查询条件会好到哪里去？

我们也知道在 JDK8 中新的时间 API LocalDateTime 中，有着丰富的时区转换的方法可用，但即便你说你精通 LocalDateTime 的各种花式用法，你也不得不面对繁杂的转换。

所以，我们需要一个拥有「绝对是时间」，来帮助我们记录日期，帮我们节省下转换的时间，这个「绝对时间」就是时间戳，时间戳的定义是从一个基准时间开始算起，这个基准时间是「1970-1-1 00:00:00 +0:00」，从这个时间开始，用整数表示，以秒计时，随着时间的流逝这个时间整数不断增加。这样一来，我只需要一个数值，就可以完美地表示时间了，而且这个数值是一个绝对数值，即无论的身处地球的任何角落，这个表示时间的时间戳，都是一样的，生成的数值都是一样的，并且没有时区的概念，所以在系统的中时间的传输中，都不需要进行额外的转换了，只有在显示给用户的时候，才转换为字符串格式的本地时间。

而且很重要的一点就是，在现有的编程语言中，都提供了方法来获取时间戳，这对于我们不同语言的项目交互来说，不要太方便！所以在这里我强烈建议前后端关于时间的交互，都用时间戳来交互。

这时，可能有同学又来杠一波，你用一个出数值来表示时间，我查数据库时，以我的眼力和口算，根本不知道时间是多少，我觉得这个根本不需要担心啊，你查数据库无非是查看需要的数据而已，你在 sql 里面对时间戳字段加个转换函数就好了，比如：

from_unixtime(1561053690000)

以上时间戳是我写这篇文章的时间。

如果你还要继续杠，说我就是要在数据库表中看到时间，我觉得如果你要这样，为什么还需要前端，直接拿数据库当前端展示就好了。

我总结一下数据库用数值保存时间戳的诸多好处：

1.在数据库中日期比较不要太方便，小学一年级就会的数学题，而且性能好；2.数值对于任何系统交互来说都不存在障碍；3.基于绝对时间的数值存储，不存在时区问题；4.在交互过程中，摒弃没必要的重重转换，一个数字走天下，用户需要显示，前端只需要拿到时间戳显示正确的本地时间；5.解决了由于各个数据库对于时间实现的不一样导致的问题，比如说 Mysql 的时间函数跟 Oracle 会有一些差别，假如你现在的 sql 有某些时间函数，换了数据库很可能就会出错。

近期热文

我对支付平台架构设计的一些思考

聊聊Tomcat的架构设计

从源码的角度解析线程池运行原理

RocketMQ消息发送的高可用设计

深度解析RocketMQ Topic的创建机制

RocketMQ源码分析之路由中心

mybatis-plus源码分析之sql注入器

钟同学，this is for you！

Mybatis-spring源码分析之注册Mapper Bean

基于Jenkins Pipeline自动化部署

Dubbo服务暴露之注册地址和端口

Dubbo全链路追踪日志的实现

长按可以订阅