Monodb日期存储差8小时分析与解决，同时引出时间分析

UTC(世界标准时间) 其以原子时秒长为基础，在时刻上尽量接近于格林尼治标准时间。

GMT(格林尼治平时) 位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本初子午线被定义在通过那里的经线。

CST(北京时间) 中国标准时间。在时区划分上，属东八区，比协调世界时晚8小时，记为UTC+8 / GMT+8。

我们在java中new一个时间对象，看一下是怎么样的时间。 通过上图可以看出，这个时间是CST，同时还是Asia/Shanghai地区的。这就奇怪了，程序是怎么知道我们的所在地区呢？其实，如果我们什么都不设置，程序默认是读取系统时间的。

有了以上两个基础知识，现在我们要分析Mongodb的时间问题。通过java的MongoTemplate新增保存的日期，数据库中存储的日期会少了8小时。 在com.mongodb.util.JSONSerializers源码类中的LegacyDateSerializer内部类中，mongodb对存储日期做了如下处理： 从源码中可以看到，Mongodb在存储时间的时候，会把UTC格式存为GMT格式。

Mongodb虽然减了8小时进行存储，但通过程序查出到Date对象的时候，神奇的事情发生了，差的8小时居然回来了，这又是为什么呢？ 我们用Date的特性套进这个问题分析一下，由于数据库存储的时间格式为GMT，系统的格式为CST（UTC+8），所以当数据查出来赋值给Date的时候，jdk或者MongoTemplate代码帮我们把GMT转成了CST。虽然我没有找到源码来验证这个过程，可是通过断点数据更加印证了我的猜想，如下：

如果你一定要把当前时区的时间存储到Mongdb中，可以在存储到Mongo前给时间加上8小时，代码就不贴了，网上一搜一大堆。

当后端返回Date类型到前端的时候，需要在实体中增加@JsonFormat注释，这个可以帮我们处理格式化，很多人都是用下面这种写法。

这样写大部分时候都不会有问题，但是有可能会出现加了8小时还是少了1小时的问题。 这是因为GMT+8代表的是东时区，不代表中国时区，Asia/Shanghai 这个代表的是中国的时区，但在历史中，有国家（包含中国）政策颁布了在1986-1991年等还存在夏令时。在这样的时间区间，夏季时，会将时间拨快1个小时（即东9区时间），夏季结束时会再次将时间拨回一个小时（即东8区时间）。所以我们要把上面的代码修改成如下：

其实这个文章不止为了研究Mongodb的时间问题，很多其他的时间问题都可以套用这个分析过程进行分析解决，只要理解清楚时间的格式。