【分享】时间国际化落地和经验分享

前言：

随着产品的不断迭代，平台产品遇到不同时区的时间问题，涉及到不同时区前端的日期展示问题，后面落地时间国际化，在这里跟大家分享一下。

---

数据存储时间：

以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，统一使用时间戳可以解决，不同服务在不同时区导致的时间问题。如果非要传时间格式，必须传递对应时区避免出现时区问题

---

定时任务：

定时任务分两种，一种是在调度中心的定时任务，一种是服务内部的定时任务；

定时任务一般都是直接按照本地时间执行；
除非是特殊节日，其他时间都可以使用时间戳

---

总结

• 显示时间跟存储时间分离
• 前端通过用户当地时区转换时间戳
• 后端定时任务直接用时间戳
• 服务直接交互用时间戳/时区和时间