.
前言
日期和时间是每个系统，每个数据库设计必不可少的部分。也是容易被大家忽视的部分。很多开发者可能根本不了解以不同类型存储日期和时间意味着什么。
有朋友可能会说，数据库定义一个datetime或timestamp类型的字段，然后在Java代码中获取当前时间并存入数据库不就可以了吗？
Date now = new Date();
// 调用insert或update方法创建或更新日期字段。
最近设计新系统的数据库，涉及到跨时区的问题，于是专门调研了不同日期时间类型的利弊，也咨询了不少同行使用的情况。这里分享给大家。
常见的日期时间使用情况有如下几种：字符串、Datetime、Timestamp、Unix timestamp。如果将日期和时间具体拆分细化又可包含DATE、TIME、YEAR，这部分我们这里暂且不过多讨论。
字符串存储日期
把日期和时间当做一个字符串进行存储，进而将日期和时间拆分成两个字段，一个字段记录日期（如yyyy-MM-dd）,另外一个字段存储时间（如：HH:mm:ss）的形式。
此种方式就不多说，除非极个别的场景，不建议使用。当使用此种方式进行处理日期，不仅性能有问题，比较、处理、取范围等都是麻烦事。
之所以提出这种方式，也是提醒大家，如果你的数据库日期字段还在用字符串存储，需要慎重考虑一下了。
DateTime类型
DateTime类型存储的值既有日期又有时间。我们直观看到的格式为：yyyy-MM-dd HH:mm:ss。它支持的时间范围是“1000-00-00 00:00:00”到“9999-12-31 23:59:59”。
但DateTime中并未存储时区信息，只存储了本地时间。也就是说：如果你将服务器的时区进行修改，数据库中记录的日期和时间并不会对应的变化。
那么，读出的数据与新存储的数据便是不一致的，也可以说是错误的。
通常，针对此种情况，如果涉及到跨时区问题，可考虑单独用一个字段来存储时区。
Timestamp类型
Timestamp类型：也是既有日期又有时间的数据。存储和显示的格式跟Datetime一样。支持的时间范围是“1970-01-01 00:00:01”到“2038-01-19 03:14:07”。
Timestamp类型不仅存储了日期和时间，还存储了时区信息。如果以Timestamp类型存储，各数据库的实现会有所不相同，有的进行了内部时区自动转换。
如果应用服务器的时区和数据库服务器的时区不一致，你无法确定数据库驱动程序会不会自动帮你转换。
同时，时间范围是Timestamp硬伤。
Unix timestamp
由于时区问题，地球上不同地方的人看到太阳升起的时间是不一样的。比如欧洲和北京时差有6-7个小时，当早上8点在北京看到太阳时，欧洲还处于凌晨1-2点。
除了上面所说的通过Timestamp类型存储包含时区的日期和时间外，还可以通过“绝对时间”来进行计算，单位为秒。
在计算机中，当前时间是指从一个基准时间（1970-1-1 00:00:00 +0:00）到现在的秒数，用一个整数表示。
在Java编程语言中我们可以通过如下两种方式（这里单位为毫秒）获取：
System.currentTimeMillis();
// 需要JDK8以上版本
Instant.now().toEpochMilli()
那么，我们只需要将表示绝对时间的时间戳通过Long类型或float类型保存到数据库中，当不同时区使用时直接格式化成对应的字符串就可以了。对应数据库类型为Bigint或float。
关于使用绝对时间戳的好处有以下几项：
1、数据存储的时区问题不存在了，只是一个绝对的数值。
2、比较时也很简单，只用比较两个数值的大小或范围即可，范围可采用between(?, ?)形式的SQL。
3、显示问题也很容易处理，各个展示端，只需要根据所在时区对数值进行转换即可，即便是JavaScript也能正常处理。
有朋友可能会说，数据库的可读性太差。在调研时我也遇到类似的疑问，后来咨询了架构师的朋友，他说mysql提供了丰富的函数，可以进行转换。
上图中，数据库存储的是毫秒数，通过FROM_UNIXTIME函数，在查询时将其转换成指定格式即可。如果你的数据库存储的单位为秒，则在SQL中无需除以1000。
关于日期时间的其他事项
为了调研数据库日期和时间的设置，也参考了阿里的开发手册，阿里使用的是datetime类型。
阿里的开发手册不是神则，很多都可以借鉴,但是不一定要去使用；就如上情况而定，如果是国内项目，建议使用datetime类型；如果是涉及到跨区域，跨时区的项目，建议使用 long 型的绝对值时间，这样只要稍微一做处理，就可以完美避开因为时区而导致系统时间显示的问题。
