- 忽略milliseconds, length = 10
"created_at": 1360019238
- length = 13
"created_at": 1360019238123
- 忽略milliseconds
"created_at": "2008-01-14T04:33:35Z"
"created_at": "2008-01-14T04:33:35.123Z"
"created_at": "Sat, 21 Aug 2010 22:31:20 +0000"
"created_at": 1360019238
"created_at": 1360019238123
"created_at": "2008-01-14T04:33:35Z"
"created_at": "2008-01-14T04:33:35.123Z"
"created_at": "Sat, 21 Aug 2010 22:31:20 +0000"
![]() |
1
binux 2014-02-21 12:37:54 +08:00
我喜欢Unix time,容易处理
当你有一个能处理ISO-8601的类库的时候,一定能将时间戳转换成ISO-8601 当你没有一个ISO-8601的时候,时间戳也可以简单地进行计算加工 |
![]() |
2
cfddream OP @binux 是的,Unix time在没有parse的情况下,还能很好的进行计算加工;ISO-8601在可读性、human-readable上有自己的优势
|
![]() |
3
justfindu 2014-02-21 12:59:17 +08:00
话说你是做接口 要可读性做什么~ 如果是展示用 前端格式化. 数据的话还是unix time好~
|
![]() |
4
9hills 2014-02-21 13:06:36 +08:00
从parse的角度上讲,ms级的timestamp最好。也不用处理时区问题
|
![]() |
5
flytwokites 2014-02-21 13:08:51 +08:00 ![]() 我弄不明白是的http之类的协议为什么要弄个human readable的日期格式,这是协议,是程序来parse的,不是给人看的,弄得这么复杂作者纯粹是个蛇精病。
|
![]() |
6
coosir 2014-02-21 13:22:58 +08:00
Unix time
|
![]() |
7
cfddream OP @flytwokites 以上是大家比较常用的格式,各自都有优势和特点;选择team统一、喜欢的风格就行。
再说现在各语言的日期时间解析库也在不断完善,也不是什么大的问题。有意思的是Dropbox API 选择了第三种格式 https://www.dropbox.com/developers/core/docs。 |
![]() |
8
dorentus 2014-02-21 13:27:04 +08:00
@flytwokites JSON、XML、YAML 什么的,其实就是为了给人类看的啊,在此前提下再设计成机器可解析格式的……
|
![]() |
9
NemoAlex 2014-02-21 14:00:43 +08:00
Unix time
ISO-8601 可读性就很好吗?时区是个问题啊 |
![]() |
10
qhxin 2018-10-26 14:47:40 +08:00
支持使用 ISO-8601,有一个关键的问题是,如果用户提交的日期转换为 ts 提交不保存时区的话,在其他时区复原用户提交的那个日期是不可能的,因为 timestamp 还原为日期字符串必须知道它是在哪个时区生成的,ISO8601 自带了时区信息,非常灵活。
|
11
miwang 9 天前
我喜欢用 unix timestamp ,这要不会错,好统一,实际读取的时候根据用户时区可以实时转换成当地时间。就是转换的时候要仔细一点,我有时候会用一些在线转换工具,比如 https://timestamptodate.org
|