提交时间给后端用时间戳好还是字符串好

[qzhai]

后端让我传如下字符串格式。 2021-12-24 16:23:39 我印象里一直传的时间戳。 我们这个业务没有涉及到 90 年以前的数据。 但是访问量很大。 说想问下 这两者的区别

[FrankFang128]

ISO 8601 +1

[edward1987]

ISO +1, 字符串才有可读性啊 而且 iso 格式的并不会存在市区问题

[lululau]

一直没弄明白，1640336120 这样的叫时间戳，2021-12-24 16:23:39 这样的为什么就不是时间戳呢。。。

[fan776783]

@lululau 没有时区信息

[BJL]

@lululau 因为没有时区信息,你这个字符串是哪个时区的字符串,美国下午四点和中国下午四点可是两个时刻

[unco020511]

@lululau 因为时间戳与时区无关,但 2021-12-24 16:23:39 与时区关联

[BJL]

看情况,我们中间换前端就顺便从时间戳改成了字符串;前端水平不够,应该传 UTC 时区 0 点的传了国内时区 0 点进来(或者反过来;还不如传字符串呢

[zen1]

什么场景下会要求前端传时间给后端呢

[leogm9408leo]

时间戳，不然出了时区的问题会扯皮

[wolfie]

@lululau #23
JS 为例，new Date().getTime() 世界各地生成值都相同（当前机器时区设置正常情况下）

[Kininaru]

处理字符串头都大了，各种格式，时区要考虑，还是时间戳好（

[Innovatino]

当然是时间戳了

[h1104350235]

肯定是时间戳

[jinliming2]

@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 字符串来显示。

[watzds]

时间戳，不容易出错，就调试稍微麻烦点，手边备一个转换器就行

[Qseven]

@zen1 这样的场景不是太多了么，随便一个列表，根据开始时间结束时间搜索。

[thinkershare]

并没有统一规范, 按照系统其它地方处理, 字符串也不存在时区的问题, 只要前后端约定好单一格式, Unix 时间戳只是为了方便偷懒

[pengtdyd]

说时区问题的非常对，但是有考虑过很多公司的项目周期只有一年甚至半年吗，有考虑过大部分系统都只有中文吗，管他时区不时区，只要时间有问题那一定是运维的锅。

[kiripeng]

时间戳+1

[jorneyr]

没啥好不好，统一让怎么用就怎么用，对错没那么重要，何况还各有道理。