在将时间数据传输到/从Web API时，为什么我会选择使用ISO8601字符串而不是UTC纪元值？例如，以下两个值相同：
Epoch = 1511324473
iso8601 = 2017-11-22T04:21:13Z
时代值长度显然较短，对于移动数据使用来说总是有益的，并且将时代值和语言的本地日期类型变量相互转换也很简单。
我只是看不到使用ISO字符串值的好处。
2个回答
18
两种日期格式都很明确且易于程序解析。像您提到的时间戳一样，它的好处在于它更小，能够更快地在程序中处理。缺点是对人类来说毫无意义。
ISO8901日期格式本身易于阅读，不需要用户将数字转换为可识别的日期。与诸如图像之类的大得多的东西相比，ISO8601格式所需的空间增加是微不足道的。
个人而言，在API中，我会选择易于阅读而非速度，因为这样可以减少调试时检查发送和接收值的时间。在另一种情况下，例如在内部传递时间时，您可能希望选择整数的速度而不是文本，因此取决于哪种方法对您更有用。
- Qwertie
3
7建议使用64位整数来表示时间戳。32位整数在2038年会溢出。 - Ole V.V.
1有关@OleV.V.评论的进一步阅读：https://en.wikipedia.org/wiki/Year_2038_problem - gmarmstrong
我只看到 EPOCH 的一个缺点，那就是它不可读，但对于系统来说很好。 - Ravi Parekh
14
Unix/Epoch Time
+紧凑
+可以进行算术运算而无需任何库，例如var tomorrow=now()+60*60*24
-不可读
-不能表示1970年1月1日之前的日期
-如果使用Int32，不能表示2038年1月19日之后的日期
-时区和偏移量是“外部”信息，如果该值是UTC或任何其他偏移量，则存在模糊性。
-官方规范仅支持秒。
-当有人将值更改为毫秒以获得更好的分辨率时，存在该值是秒还是毫秒的歧义。
-早于ISO 8601格式
-表示自1970年以来的秒数（与时间点相反）
-精度为秒
ISO 8601 时间格式
+易于阅读
+表示时间点，而不是自1970年以来的秒数
+比Unix时间格式更新
+指定了日期、时间、日期时间、持续时间和间隔的表示方式！
+支持一个偏移量的表示
+精度为纳秒
-不够紧凑
-需要使用丰富的库进行任何算数操作（如java.time.OffsetDatetime）
- Igal
4
3秒数自1970年1月1日UTC 00:00:00起算不会存在任何二义性，这是根据定义而言的。如果您“转换”带有时区偏移量的时间戳，那么这是用户错误。这不是时间计算系统的问题，而是被误用了。同时，一个人可以表示1970年以前的时间-最早可表示的日期是1901年12月13日星期五（1970 + INT32_MIN）。整数是有符号的，你可能记得… - Johannes Pille
时区设置为“外部”是一件好事，因为Unix时间在所有时区中都是相同的。 - mismaah
1@JohannesPille 可能会出现歧义，例如，如果API期望自纪元以来的毫秒数（而不是秒数）。在这种情况下，当客户端错误地提供以秒为单位的时间并且服务将其解释为毫秒时，就会发生重大的误解。最糟糕的部分是，这种误解对双方都不明显，因为它很可能被解释为时间的有效表示。 - Ben Coppock
你提到了一个时代的负面之处是"表示自1970年以来的秒数（与时间的瞬间相对）"。难道ISO日期也不是表示一个时间相对于另一个时间（即基督降生2000年后）吗？所有关于时间的表述都是相对的，没有与其他时间进行比较的"瞬间"存在。 - JMadelaine
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接