有个 web 服务时区问题,后端服务和数据库都统一使用 utc+0 时区,由前端根据访问者所在时区进行格式化,现在问题是用户新增数据时,应该让前端传创建时间还是使用服务器时间,如果使用服务器时间,则创建的数据时间和展示给用户的时间可能不一致(比如用户是东八区,服务器按 0 时区存,展示时就差了 8 小时),如果让前端传创建时间,这个创建时间不可靠,用户可能通过非法手段修改,想咨询大佬有没有很好的解决时区的办法
1
XiLingHost 2023-10-23 21:28:59 +08:00
统一传时间戳啊,然后展示让前端做
|
2
ysc3839 2023-10-23 21:30:31 +08:00 via Android 2
“比如用户是东八区,服务器按 0 时区存,展示时就差了 8 小时”
为什么会呢?你前面不是说“由前端根据访问者所在时区进行格式化”吗? |
3
ho121 2023-10-23 21:32:19 +08:00 via Android
一般是按照服务器时间。
展示也要转换时区再展示的啊。 |
4
WhateverYouLike 2023-10-23 21:37:23 +08:00 via Android
2 楼加一
|
5
ratazzi 2023-10-23 23:15:35 +08:00
创建、更新等时间都是以服务器为准,必须要客户传的比如预约、达到时间等之类的才会用客户的
|
6
ETiV 2023-10-23 23:30:29 +08:00 via iPhone 1
奇异博士告诉我们:不要玩弄时间
1. 确定服务器开了 ntp 同步服务。明令禁止人肉修改时间 2. 数据库里存 int64 数值形式的时间戳(你自己考虑秒、毫秒、微秒这类精度需求) 3. 应用业务根据时间戳自行转换成 human-readable 的时间字面量(带时区),浏览器 JS 有个 toLocaleString 很好用 4. 永远不要使用客户端提交的时间,极有可能存在客户端时间不准确、甚至故意改时间来达成一些目的的情况 |
7
Mithril 2023-10-24 00:26:48 +08:00
你存 UTC ,从数据库里读出 UTC 你也要按客户时区转换一下啊,怎么可能差 8 小时。
本质上你数据库应该保存的是 instantaneous time ,而你展示给客户的应该是 calendar time ,这个转换应该在前端完成。 比如说你客户 A 从-8 生成了一个数据,存在数据库里的应该是+0 ,而展示给+8 的客户 B 应该就是+8 。如果你关心数据生成的时区,那应该用另一个 field 去保存,或者你存成 datetimeoffset 。 至于 instantaneous time 和 calendar time 的区别,这里有个很好的解释你可以参考一下: https://stackoverflow.com/questions/4331189/datetime-vs-datetimeoffset |
8
baobao1270 2023-10-24 05:17:43 +08:00
|
9
XueXianqi 2023-10-24 09:37:50 +08:00
@XiLingHost 那到 2038 年之后呢
|
10
ShuWei 2023-10-24 09:45:56 +08:00
这个可以分情况讨论,第一种是业务字段的时间,比如用户预约一个什么时候的服务,这个完全可以跟客户端约定一个带时区信息的时间格式就好了,比如 RFC3339 ,另一种是非业务字段的时间,比如数据库存的数据创建时间、最后更新时间之类的,就服务器自动生成即可
|
11
XiLingHost 2023-10-24 14:22:20 +08:00
@XueXianqi 用 u64 呗
|
12
flyqie 2023-10-24 15:44:02 +08:00 via Android
|