系统开发中的时间类型的处理问题

2019独角兽企业重金招聘Python工程师标准>>>

这两天做了个测试程序放到cloudfoundry上，测试的时候突然发现系统中对日期时间类型的数据处理在云环境下存在问题。

仔细思考以后发现这个问题是一直存在的，只是以前自己做的系统没有考虑到多时区并发的问题而已。

现象：

开发环境：jdk 6, mysql，vaadin framework

所有的日期时间字段都用datatime类型存在mysql数据库中，部分时间的取得是在服务端用new Date()，部分时间是由客户端post上来，格式是“yyyy-MM-dd HH:mm:ss”。存储到数据库中时是格式化为“yyyy-MM-dd HH:mm:ss”插入datetime字段。

根据cloudfoundry对云应用的注意事项的提示，我们可以知道，我们无法预测APP会在哪台虚拟机上运行，不能上传文件到虚拟机（除非使用存储服务），因为下一次重启你的APP不一定在同一台机器上，你也不知道什么时候APP会重启；同样你也不会知道你的APP所驻留的虚拟机是什么时区以及地区。

所以，现有程序中的处理就有问题了，如果客户端的时区和服务端不同，所有的时间存储和依赖于时间值的查询都会是错的。

所以，要么存储时间时要同时存储时区，要么所有时间值都转换成一个统一的时区。

处理时考虑的因素：

mysql中的datetime是不存储时区的，而timestamp是utc时间，精确到秒，不能处理毫秒。而不同的数据库timestamp的处理是不一样的，例如ms sql里timestamp已经不建议使用了，也不承诺就是当时的时间戳。

java中的Date类型本身是utc时间，new的时候会记录环境时区，以及toString时根据记录的时区输出字符。

Date类型的getTime输出的永远是精确到毫秒的UTC时间，不用操心时区转换的问题。

结论：

使用8字节整数，数据库中用BIGINT来存储时间，存储前getTime()获得long型的utc时间后存储。取出时，获取后用new Date(long)生成日期类型，如要传回给客户端，根据客户端时区重设Date后传出。

转载于:https://my.oschina.net/fornews/blog/128419