纪元还是 iso8601 日期格式？答案

【问题标题】：Epoch or iso8601 date format?纪元还是 iso8601 日期格式？
【发布时间】：2018-05-05 17:23:36
【问题描述】：

对于在 JSON 中与 Web API 之间传递时间，为什么我会选择使用 ISO8601 字符串而不是简单的 UTC 纪元值？例如，这两个是相同的：

Epoch = 1511324473
iso8601 =   2017-11-22T04:21:13Z

epoch 值的长度显然更短，这对移动数据使用总是有利的，并且在 epoch 值和语言的本地 Date 类型变量之间进行转换非常简单。

我只是没有看到使用 ISO 字符串值的好处。

【问题讨论】：

【解决方案1】：

两者都明确且易于在程序中解析。您提到的 epoch 的好处是它更小，并且在您的程序中处理起来会更快。缺点是它对人类毫无意义。

iso8901 日期本身易于阅读，不需要用户将数字转换为可识别的日期。与图像等更大的东西相比，iso8601 的大小增加并不明显。

就我个人而言，我会为 API 选择易于阅读而不是速度，因为它会在检查发送和接收的值时减少调试时间。在另一种情况下，例如在内部传递时间，您可能希望选择整数而不是文本的速度，这取决于您认为哪个更有用。

【讨论】：

【解决方案2】：

Unix/Epoch Time
+ 紧凑

+ 无需任何库即可轻松进行算术运算，即var tomorrow=now()+60*60*24

- 不可读

- 不能表示 1970 年 1 月 1 日之前的日期

- 不能表示 2038 年 1 月 19 日之后的日期（如果使用 Int32）

- 时区和偏移量是“外部”信息，如果值是 UTC 或任何其他偏移量，则存在歧义。

- 官方规范只支持秒。

- 当有人将值更改为毫秒以获得更好的分辨率时，如果该值是秒或毫秒，则会产生歧义。

- 早于 ISO 8601 格式

- 表示自 1970 年以来的秒数（与即时相对）

- 秒精度

ISO 8601 Time
+ 人类可读

+ 表示时间的瞬间，而不是自 1970 年以来的秒数

+ 比 Unix 时间格式更新的格式

+ 指定日期、时间、日期时间、持续时间和间隔的表示形式！

+ 支持偏移表示

+ 纳秒级精度

- 不那么紧凑

- 对于任何算术动作，都需要到达库（如 java.time.OffsetDatetime）

【讨论】：

自纪元以来的秒数零歧义，因为纪元开始于 0:00:00 01-01-1970 UTC，根据定义。 b> 如果您“转换”带有时区偏移量的时间戳，则属于用户错误。这不是计时系统的错，它被滥用了。此外，一个可以表示远在 1970 年之前的时间 - 可表示的最小日期是星期五 1901-12-13 (1970 + INT32_MIN)。整数是有符号的，你可能还记得...
时区为“外部”是积极的，因为所有时区的 Unix 时间都是相同的。
@JohannesPille 歧义可能会蔓延，例如如果 API 期望自纪元以来的毫秒数（而不是秒数）。在这种情况下，当客户端错误地以秒为单位提供时间而服务将其解释为毫秒时，就会出现严重的错误传达。然而，最糟糕的是，这种错误沟通对任何一方来说都不是很明显，因为它很可能被解释为一个时间的有效表示。