web 开发涉及到时间的是一律使用 utc 时间吗?

2016-07-21 15:26:34 +08:00
 myyou
8351 次点击
所在节点    Python
61 条回复
allenhu
2016-07-21 19:23:55 +08:00
搞清楚你的应用几国人在用,生命周期是多久,就清楚了
haozhang
2016-07-21 19:49:12 +08:00
@loading 我说的是日期错位啊...
caixiexin
2016-07-21 19:59:05 +08:00
小于 1970 年的 Unix 时间戳,不是负数吗
kookxiang
2016-07-21 20:02:48 +08:00
unix 时间戳是到 2038 年?那只是因为你用 32 位的 int 来存而已吧
lizon
2016-07-21 20:08:12 +08:00
64 位的机器会有这个问题吗?
skydiver
2016-07-21 21:39:51 +08:00
@loading 千年虫不是闰年问题,是年份只用了两位整数来存的问题
skydiver
2016-07-21 21:40:15 +08:00
@myyou 用 64 位来存就没有 2038 问题了
onlyice
2016-07-21 22:03:37 +08:00
expkzb
2016-07-21 22:10:21 +08:00
时间戳的问题在于不能表示时区,遇到航班信息就傻眼了
loading
2016-07-22 06:17:05 +08:00
@skydiver 其实就是闰年问题。
loading
2016-07-22 06:18:41 +08:00
@skydiver 哦,闰年问题是带来的主要问题之一…特别明显。
tausi0661
2016-07-22 08:34:21 +08:00
是不是 utc/unix 无所谓, 只要存储的所有时间是统一的时区就好, 并保证各 server 的时区及时间一致.
lifanxi
2016-07-22 08:53:40 +08:00
@loading
重复一下 26 楼的话:千年虫不是闰年问题,是年份只用了两位整数来存的问题。参考老版的 13 位身份证号码来理解。

2000 年是闰年,而 1900 年不是,如果把 2000 年误作 1900 年,确实会造成 2 月少一天的问题。但这不是通常“千年虫”讨论的范畴,也不是像你说的那样,因为“千年虫是判断 2000 年是闰年,少了一个判断”, 2000 年是闰年没有问题,你说的“少了一个判断”(能否整除 400 )只会造成把 1900 年也判成闰年。
mengzhuo
2016-07-22 09:05:43 +08:00

等你们公司开始做国际化的时候 后面的程序员会感谢你的
xuboying
2016-07-22 09:09:12 +08:00
@expkzb 航班时间这种涉及跨时区的不用时间戳才傻了。记录了时间戳用户才能得到不同时区的时间正确表示,特别是还有地方有夏时制冬时制,每次显示都要换算正确
lifanxi
2016-07-22 09:18:03 +08:00
时间其实是个很复杂的东西,但是可以把它理解成是个自然流逝的东西,然后人为给每一秒(毫秒也行,单位不重要,取决于你需要精度)进行计数。

这个计数值在计算机领域通常可以用 Unix 时间戳来表示,在不考虑实现(变量位数)的前提下,这个计数值可以表示任意时间范围。所谓只能表示 1970-2038 是因为假设了只用有符号 32 位整型数的非负数部分对秒计数的原因。

所以,用一个足够长的有符号整数来表示任意时间是没有问题的。但这个数值本身并不具有“时区”的含义,时区只在把它转换为人类可读的表示方式时才要考虑的问题。

这个转换工作应该 100%交给操作系统去实现,而不应该自己土法按一年 365/366 年、每天 24 小时、每小时 60 分钟、每分钟 60 秒再加上时间偏移去计算,甚至前一天、后一天这种计算也应该用系统库去完成,而不要自己去做。

因为时间日期计算里有太多坑了,基本上 99.9%的程序员自己实现的版本不会比系统已有的版本要好。最简单的有闰年、复杂一点的时区和夏时制、再复杂一点有闰秒、更复杂一点是一些历史特殊情况(比如时区变更)。
yaodong
2016-07-22 09:21:56 +08:00
http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html


> TL;DR Use UTC as the only timezone for your servers.
BlueMeow
2016-07-22 10:20:05 +08:00
@lifanxi 对。有时候由于临时增加的闰秒、地区时区调整、夏令时等问题,时间存在处理各种陷阱。比如 http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result 这个问题就是因为 1927 年上海时区调整引起的,这种细节自己处理的话总会有疏漏。
bingwenshi
2016-07-22 11:42:29 +08:00
做个编程习惯良好的工程师,把时间都存储成 UTC 时间, 只是在展示的时候,根据用户时区再做转换就行了
julyclyde
2016-07-22 11:58:03 +08:00
使用 UTC 可以保证时序
不要忘了所谓弟弟比哥哥先出生的夏令时事故

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/293957

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX