为了在JSON中向/从Web API传递时间，为什么我会选择使用ISO8601字符串而不仅仅是UTC纪元值？例如，两者都是相同的：
Epoch = 1511324473
iso8601 = 2017-11-22T04:21:13Z
时间长度明显更短，这对于移动数据的使用总是有利的，并且在纪元值和语言的本地日期类型变量之间进行转换非常简单。
我没有看到使用ISO字符串值的好处。
答案 0 :(得分：5)
两者都是明确的，易于在程序中解析。像你提到的epoch的好处是它更小，并且在你的程序中处理起来会更快。缺点是它对人类没有任何意义。
iso8901日期易于自行阅读，并且不要求用户将数字翻译成可识别的日期。与像图像这样的大得多的东西相比，iso8601的尺寸增加是不明显的。
就个人而言，我会选择简单的API读取速度，因为它会在检查发送和接收的值时减少调试时间。在另一种情况下，例如在内部传递时间，您可能希望选择整数而不是文本的速度，这取决于您认为哪个更有用。
答案 1 :(得分：4)
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）