时代还是iso8601的日期格式？

Question

对于将JSON中的时间传递到/从web传递，为什么我选择使用ISO8601字符串而不是简单地使用UTC时代值？例如，这两者是相同的：

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

历元值的长度明显较短，这对移动数据的使用总是有利的，在历元值和语言的本地日期类型变量之间进行转换非常简单。

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

Answer 1

两者都是明确的，易于在程序中进行解析。正如您所提到的，时代的好处是它更小，并且在您的程序中处理得更快。缺点是它对人类毫无意义。

iso8901日期很容易单独读取，并且不要求用户将数字转换为可识别的日期。与像图像这样的大得多的东西相比，iso8601中的尺寸增加是不明显的。

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

Answer 2

Unix/Epoch时间

• 紧致
• 不需要任何库，即var tomorrow=now()+60*60*24，很容易完成算术操作
• 非人类可读的
• 不能代表1970年1月1日前的日期
• 无法表示2038年1月19日以后的日期(如果使用Int32)
• 时区和偏移量是“外部”信息，如果值为UTC或任何其他偏移量，则存在模糊性。
• 正式来说，规范只支持秒。
• 当某人将值更改为毫秒以获得更好的分辨率时，如果值为秒或毫秒，则会出现模糊。
• 早于ISO 8601格式
• 表示自1970年以来的秒数(相对于即时时间)
• 秒精度

ISO 8601时间

• 人类可读的
• 表示即时时间，而不是1970年以来的秒数。
• 更新后的Unix时间格式
• 指定日期、时间、日期-时间、持续时间和间隔的表示！
• 支持偏移量表示
• 纳秒精度
• 不太紧
• 对于任何算术操作，reach库都是必需的(如java.time.OffsetDatetime)