后端让我传如下字符串格式。 2021-12-24 16:23:39 我印象里一直传的时间戳。 我们这个业务没有涉及到 90 年以前的数据。 但是访问量很大。 说想问下 这两者的区别
1
preach 2021-12-24 16:26:06 +08:00 1
时间戳+10086
|
2
ipwx 2021-12-24 16:26:37 +08:00
unix timestamp 你不会有时区问题。不然就等着修 bug 吧
|
3
shanghai1943 2021-12-24 16:26:59 +08:00
时间戳,提供原始数据,爱咋用咋用。
|
4
gainsurier 2021-12-24 16:27:47 +08:00
时间戳,不用再解析一下了
|
5
Mitt 2021-12-24 16:28:26 +08:00 2
字符串时间的方法可以带时区信息
|
6
liyang5945 2021-12-24 16:28:50 +08:00
字符串吧,方便调试,造参数,鬼知道那一坨时间戳数字是啥玩意
|
7
jay1002008 2021-12-24 16:30:30 +08:00
时间戳+1
|
8
beaze 2021-12-24 16:31:37 +08:00
后端都这么说了, 那就传时间戳咯(手动狗头
|
9
libook 2021-12-24 16:31:55 +08:00
时间戳,或者 ISO 8601 的字符串;非标准字符串可能信息不全,对接方也可能不知道如何处理,专门维护一种解析方案又浪费产能。
|
10
Goat121 2021-12-24 16:32:13 +08:00
这个你们约定好就行,没多大区别,如果涉及时区问题,字符串用 RFC3339 格式就行
|
11
Leonard 2021-12-24 16:33:47 +08:00
肯定是时间戳好
|
12
clf 2021-12-24 16:34:00 +08:00
时间戳的话,无论什么语言,都会有转换为时间对象的方法,而字符串的标准不一定统一。
|
13
xwayway 2021-12-24 16:37:56 +08:00
前后端交互,最好时间戳,避免时区问题,时间展示统一在前端格式化
|
14
chnhyg 2021-12-24 16:39:55 +08:00
尽量存储原始数据,也就是时间戳。
|
15
wangtian2020 2021-12-24 16:40:02 +08:00
时间戳可以直接比大小,不用转换
字符串要带上时区信息 我们是统一用时间戳的 |
16
yorek 2021-12-24 16:40:50 +08:00
时间戳,数据很原始,也没有别的副作用
|
17
masterclock 2021-12-24 16:47:01 +08:00
存什么、传什么、显示什么分清楚,不要混淆不要耦合
但无论如何,必须附带时区等信息 |
18
linglin0924 2021-12-24 16:47:53 +08:00
时间戳,需要什么格式什么时区可以自行转换
|
19
CodingNaux 2021-12-24 16:49:04 +08:00
ISO 8601
|
20
jaswer 2021-12-24 16:49:18 +08:00
时间戳+1, 出了 bug 和你无关
|
21
FrankFang128 2021-12-24 16:50:02 +08:00
ISO 8601 +1
|
22
edward1987 2021-12-24 16:52:11 +08:00
ISO +1, 字符串才有可读性啊 而且 iso 格式的并不会存在市区问题
|
23
lululau 2021-12-24 16:56:07 +08:00
一直没弄明白,1640336120 这样的叫时间戳,2021-12-24 16:23:39 这样的为什么就不是时间戳呢。。。
|
26
unco020511 2021-12-24 17:29:31 +08:00
@lululau 因为时间戳与时区无关,但 2021-12-24 16:23:39 与时区关联
|
27
BJL 2021-12-24 17:30:40 +08:00
看情况,我们中间换前端就顺便从时间戳改成了字符串;前端水平不够,应该传 UTC 时区 0 点的传了国内时区 0 点进来(或者反过来;还不如传字符串呢
|
28
zen1 2021-12-24 17:31:07 +08:00
什么场景下会要求前端传时间给后端呢
|
29
leogm9408leo 2021-12-24 17:33:45 +08:00
时间戳,不然出了时区的问题会扯皮
|
30
wolfie 2021-12-24 17:40:24 +08:00
@lululau #23
JS 为例,new Date().getTime() 世界各地生成值都相同(当前机器时区设置正常情况下) |
31
Kininaru 2021-12-24 17:44:23 +08:00
处理字符串头都大了,各种格式,时区要考虑,还是时间戳好(
|
32
Innovatino 2021-12-24 17:44:52 +08:00
当然是时间戳了
|
33
h1104350235 2021-12-24 17:50:38 +08:00
肯定是时间戳
|
34
jinliming2 2021-12-24 17:55:51 +08:00
@lululau 楼上说的“时间戳”根据语境,应该特指的是“unix 时间戳”,也就是用整数来表示 UTC 时区 1970 年 1 月 1 日 0 点 0 分 0 秒开始的秒数(有些编程语言是毫秒数)……
而“时间戳”本身就是描述一个具体时间的抽象概念,具体是拿 int 来描述、拿 string 来描述、甚至拿 bitmaps 来描述都可以的。 存储时间一定得考虑时区,即使你现在还遇不到时区的问题,但未来总会遇到,遇到就是 bug 。 所以只要使用带时区信息的方式存,就绝对没问题。通常这两种带时区的方案用的比较多: 1 ,使用 unix 时间戳 / 数字时间戳,时区信息是带在<定义>里的,固定 UTC 时区,存的时候转成 UTC 时间存,读的时候根据需要转成对应时区来显示。本身 unix 时间戳是表示秒数的,部分编程语言实现为整型的毫秒数,或者以小数的形式带上毫秒信息,就统一叫做数字时间戳了。 2 ,使用标准的 RFC 3339 ,这是 ISO 8601 的一个固定格式变体(存储的时候不建议使用宽泛的 ISO 8601 ,带了很多没必要的东西。读取显示的时候到无所谓),这个时间格式里是带着时区信息的,Z 结尾表示 UTC 时区,当然也可以存成其他方便阅读的时区。 通常建议是存成整数数字时间戳,因为对计算机来说,整数是最高效的,进行时间比较也是最方便的,占用空间也是最小的。而在需要人阅读的时候,根据需要转换为阅读者所在时区的 RFC3339 / ISO 8601 字符串来显示。 |
35
watzds 2021-12-24 17:57:25 +08:00
时间戳,不容易出错,就调试稍微麻烦点,手边备一个转换器就行
|
37
thinkershare 2021-12-24 18:06:51 +08:00
并没有统一规范, 按照系统其它地方处理, 字符串也不存在时区的问题, 只要前后端约定好单一格式, Unix 时间戳只是为了方便偷懒
|
38
pengtdyd 2021-12-24 18:17:19 +08:00
说时区问题的非常对,但是有考虑过很多公司的项目周期只有一年甚至半年吗,有考虑过大部分系统都只有中文吗,管他时区不时区,只要时间有问题那一定是运维的锅。
|
39
kiripeng 2021-12-24 18:20:15 +08:00
时间戳+1
|
40
jorneyr 2021-12-24 18:22:00 +08:00
没啥好不好,统一让怎么用就怎么用,对错没那么重要,何况还各有道理。
|
41
rrfeng 2021-12-24 18:29:46 +08:00
字符串可以,但是一定要带时区
|
43
mainjzb 2021-12-24 18:58:19 +08:00
要么 RFC 3339 和 http 一样好调试
要么 时间戳 和 grpc 一样效率高 |
44
securityCoding 2021-12-24 19:01:42 +08:00 via Android
时间戳,什么时区自己去搞,范围查询时没那么多幺蛾子
|
45
tushankaka 2021-12-24 19:04:37 +08:00
ISO8601
|
46
lff0305 2021-12-24 21:58:05 +08:00 via Android
字符串不光是时区的问题,还有夏令时的问题(如果做国际项目), 表回调那一天,有两个那个回调的小时
|
47
icyalala 2021-12-24 22:12:27 +08:00
完整的信息其实是 timestamp + zone
只传时间戳,就缺少了时区信息 而不标准的时间字符串问题更大 |
48
janus77 2021-12-24 23:12:07 +08:00
时区是一个方面
还有一个就是,如果传字符串,你前端和后端都要校验一下合法性,格式不对之类的问题 然后就是后端使用的时候更加方便,不管是转成其他格式,还是验证一下时间段,初始值用时间戳都比格式化好的字符串要方便 |
49
kisick 2021-12-24 23:18:02 +08:00 via iPhone
时间戳最保险,避免踩坑
|
50
Rocketer 2021-12-24 23:27:50 +08:00 via iPhone
国际上时间戳更流行,因为老外需要不停的处理时区问题。数据库里存的都是格林尼治时间,各客户端根据自己的时区再转换。
纯中国市场的话倒是无所谓,后端要求咋样就咋样呗。 |
51
dayeye2006199 2021-12-25 02:40:17 +08:00
朋友,时区和夏令时有没有处理过
|
52
dcsuibian 2021-12-25 02:46:47 +08:00
我用毫秒级时间戳,尽管字符串更好阅读,但实际上字符串的维护成本高很多
|
53
ETiV 2021-12-25 08:01:54 +08:00 via iPhone
unix timestamp 时间戳
严肃一点场景的话应该避免读客户端的时间戳,因为用户可以改系统时间伪造。 |
54
ericls 2021-12-25 08:35:32 +08:00 via iPhone
未来的时间只能存字符串 因为时间戳无法确定 因为夏令时的规定可能会变
|
55
chendy 2021-12-25 10:34:53 +08:00
时间+时区
直接上时间戳不容方便看 |
56
zerozz 2021-12-25 13:42:55 +08:00
时间戳的 2038 年问题如何解呢
|
57
Torpedo 2021-12-25 14:27:05 +08:00
肯定是时间戳。
字符都不知道有多少种。。。 |
58
Cbdy 2021-12-25 15:18:26 +08:00
ISO 8601 比时间戳好点
|
59
icelo 2021-12-25 19:28:59 +08:00
时间戳好点
|
60
liuidetmks 2021-12-26 06:53:35 +08:00 via iPhone
字符串要注意时区
|
61
hdfg159 2021-12-26 21:59:29 +08:00
时间戳
|
62
yogogo 2021-12-26 22:52:18 +08:00
看看是否需要处理时区问题。如果是不出国的应用,随便用
|
63
chengyiqun 2021-12-27 09:22:05 +08:00
看后端要求吧.
|
64
debuggerx 2021-12-27 10:29:46 +08:00
ISO 字符串好,原因:
1. 标准,不会出现理解偏差,节省沟通成本 2. 可读性好,时间戳不用转换器根本看不出具体时间 3. 可表示时间范围更大,不存在 2038 年溢出和无法表达 1970 年之前时间的问题 |
65
xuanbg 2021-12-27 12:46:35 +08:00
说用时间戳的,都不考虑 2038 年后的事的嘛? ISO 字符串可读性好,还没有什么限制。
|
66
NeoZephyr 2021-12-27 13:35:42 +08:00
UTC 字符串
|
67
smartwusir007 2021-12-27 17:47:05 +08:00
感觉时间戳好点,我后端,如果让我俩用字符串的话,有时候会忘了使用 utc 还是用有时区的,我推荐时间戳。但实际上我用的还是字符串多点。直接返回东八区字符串
|
68
auchan 2021-12-27 17:49:08 +08:00
最好就是时间戳
但一般都是和后端协商行了 |