这是一个创建于 1784 天前的主题，其中的信息可能已经有所发展或是发生改变。
不懂就问，如何优雅的实现以下几个需求点：
- 允许最终用户自定义时区，所有页面展示的时间都应是用户对应时区的
- 用户可以选择时间进行筛选等操作，这些操作也要适配用户对应的时区
- 服务部署的机器时区不可控
- 数据库部署机器的时区不可控
- 存在定时任务，因此定时任务的触发必须跟随设定用户的时区
此处说部署不可控的意思是想要尽量在代码层面把事情解决，最好不要对服务器本身的时区、环境配置产生依赖，以免增加系统国际化部署时的难度。
场景： 一个西 6 区的用户，设置了一个 2020-01-01T00:00:00 执行的定时任务，那么该任务在某台东 8 区的服务器上，应该在 2020-01-01T14:00:00.000+08:00 时执行。
此时一个 0 区的用户，看到这个定时任务在 2020-01-01T06:00:00.000+00:00 执行了。如果这个用户筛选 2020-01-01 00:00:00 ~ 2020-01-01 23:59:59 的任务，则应当能看到该任务。
同时，若一个西 7 区的用户，使用 2020-01-01 00:00:00 ~ 2020-01-01 23:59:59 进行筛选，则看不到该任务。因为该任务在西 7 区的执行时间为 2019-12:31T23:00:00。
7 条回复 • 2020-01-12 11:50:30 +08:00
 |
1
di94sh 2020-01-11 21:51:06 +08:00 via iPhone
统一用时间戳 server 输入输出都用时间戳，前端拿到自己转换.
|
 |
2
Citrus OP @di94sh 也就是全部使用 Long 值来进行存储、传输啦？这样确实也是可以的，但是有点小问题，就是不直观。。。如果我想排查一个问题，在 DB 或日志里拿到一个时间戳，需要转换才能知道准确时间。。。
|
 |
3
zoowii 2020-01-11 21:58:35 +08:00
时间戳 timestamp 类型或者时间戳整数或者带时区的字符串格式不就好了
|
|
4
di94sh 2020-01-11 22:45:32 +08:00
@Citrus #2 我之前一个项目 db 用 timestamp(3) 存, server 代码都用 utc 时间处理, 与前端交互都用 13 位时间戳.
|
 |
5
zeromake 2020-01-12 02:57:58 +08:00 via Android
最好数据库还是存放正常的时间只是在存取数据时转为时间戳，主要是这样数据库里的时间操作依旧能够使用
|
 |
6
conn4575 2020-01-12 08:55:31 +08:00 via Android
内部统一使用 UTC，对外接口的时间字符串使用 ISO 标准
|
 |
7
wysnylc 2020-01-12 11:50:30 +08:00 via Android
localdatetime
|
Select Language