前言：
随着产品的不断迭代，平台产品遇到不同时区的时间问题，涉及到不同时区前端的日期展示问题，后面落地时间国际化，在这里跟大家分享一下。
数据存储时间：
以MySQL为例，存储日期有DATETIME和TIMESTAMP两种类型，DATETIME是根据数据库连接，存进去是什么取出来就是什么，不会有任何转换也没有存储时区。
推荐MySQL数据存储时间戳TIMESTAMP，因为TIMESTAMP值以UTC格式保存，存储时对当前的时区进行转换，检索时再转换回当前的时区。
服务器配置数据库连接指定时区（serverTimezone）UTC，这样日期存储和检索都是零时区
url: jdbc:mysql://${
db.host}:${
db.port}/${
db.schema}?serverTimezone=UTC
可参考
MySQL中文官方文档
服务端响应客户端：
服务端返回给客户端的时间是时间戳TIMESTAMP，客户端通过用户本地时区转换时间戳显示，例如用户在北京（东八区）那么客户端会转换东八区的时间进行展示+8小时。
特殊场景可能会需要服务端返回特定时区给前端，客户端转换对应时区的时间进行展示
客户端请求服务端
客户端请求服务端，有两种方案：
- 一种方案是客户端统一转换时间戳给后端，服务端不用处理
- 一种方案是客户端传时区和时间，通过服务端进行转换时间戳或者存储时区和DATETIME
建议统一通过客户端转换时间戳，可以避免时区问题下沉到业务实现方面
不同服务之间交互：
很多场景需要不同服务之间交互，例如：
订单服务A需要通过RPC查询评价服务B，统一使用时间戳可以解决，不同服务在不同时区导致的时间问题。如果非要传时间格式，必须传递对应时区避免出现时区问题
定时任务：
定时任务分两种，一种是在调度中心的定时任务，一种是服务内部的定时任务；
定时任务一般都是直接按照本地时间执行；
除非是特殊节日，其他时间都可以使用时间戳
总结
- 显示时间跟存储时间分离
- 前端通过用户当地时区转换时间戳
- 后端定时任务直接用时间戳
- 服务直接交互用时间戳/时区和时间