为什么大多数 API 在纪元上使用 ISO-8601 时间戳格式？

Question

我见过很多epoch使用格式来表示日期的项目。但据我所知，大多数开发人员都使用ISO-8601时间戳格式。我想知道 ISO-8601 相比时代有什么好处？

我在 SO 上发现了这个问题，但一般来说更多的是关于正确的日期格式。我知道纪元时间戳通常用于表示上次更新或创建时间 - 但我认为这与数据库有关。对我来说，纪元时间戳有点令人困惑，至少因为不同的语言使用不同的时间单位（例如，在 PHP 中是秒，但在 Java、Javascript 等中是毫秒），而ISO-8601格式是标准的。

Answer 1

太长了；博士

\n

在凌晨 3 点调试关键问题时，您更愿意看到哪个值？

\n

\n
• 1668329462529
\n
• 2022-11-13T08:51:02.529Z
\n

\n

为了清晰起见，使用 ISO 8601 文本

\n

关于使用某个纪元参考的经过计数来跟踪时间，需要考虑两个问题：

\n

\n
• 各种协议使用各种粒度，例如整秒、毫秒、微秒、数百微秒、纳秒等。
\n
• 各种系统/协议使用各种纪元参考。
\n

\n

因此，遇到一个仅仅代表日期时间的数字可能会产生歧义。由于不正确的假设或沟通不畅，这些数字常常容易出错。

\n

人类思维无法将单纯的数字解析为瞬间。诸如 15687402956 或 1668329058 之类的时间戳对于普通人来说是无法读取的。因此调试变得困难。并且无效值可能会被忽视。

\n

通常，最好以标准ISO 8601格式的文本形式存储和交换日期时间值。该标准定义的格式经过精心设计，在人类文化和语言中相对清晰且明确。

\n

零偏移量

\n

通常最好报告与 UTC 的偏移量为零时-分-秒的时刻（时间线上的特定点），除非您有特定原因使用偏移量。

\n

例如，在 Java 中：

\n

Instant instant = Instant.now() ;\nString output = instant.toString() ;  // Generates text in ISO 8601 format.\n

\n

请参阅在 Ideone.com 上运行的此代码。

\n

\n

2022-11-13T08:17:31.634762Z

\n

\n

ISO 8601 字符串末尾Z的 表示偏移量为零，发音为 \xe2\x80\x9cZulu\xe2\x80\x9d。

\n

往另一个方向走：

\n

Instant instant = Instant.parse( "2022-11-13T08:17:31.634762Z" ) ;\n

\n

ZonedDateTimes

\n

请注意，ISO 8601 的一个缺点是省略了时区。该标准仅涵盖偏移量。

\n

Java 中的类java.time.ZonedDateTime明智地扩展了 ISO 8601 标准，在生成文本时将时区名称附加在括号中。ZonedDateTime相对于 an的最大优点之一是它会自动调整时区偏移（例如，在DSTOffsetDateTime的情况下或当一个国家更改其时区偏移时）。

\n

ZoneId z = ZoneId.of( "Asia/Tokyo" ) ;\nZonedDateTime now = ZonedDateTime.now( z ) ;\nString output = now.toString() ;  // ISO 8601 format extended to append the name of the zone in brackets.\n

\n

在 Ideone.com 中运行时。Continent/Region请注意末尾的正式时区名称 ( )。

\n

\n

2022-11-13T17:26:08.717876+09:00[亚洲/东京]

\n

\n

希望这种时区表示方式能够成为事实上的标准，并有一天被添加到官方标准中。

\n

定义

\n

快速回顾一下偏移量和时区：

\n

\n
• 偏移量只是UTC 时间本初子午线之前或之后的小时数、分钟数、秒数。
\n
• 时区是特定地区人民使用的偏移量的过去、现在和未来变化的命名历史，由他们的政治家决定。
\n

\n

何时使用计数

\n

我唯一会使用计数作为跟踪时间的方式的地方是资源极其有限的地方。毫秒计数只需要 32 位。

\n

在常见的商业应用程序编程中，这种需求已经基本消失。内存便宜，存储也便宜。

\n

相比之下，调试的成本很高，业务沟通不畅的成本也很高。因此，只要可行，请使用 ISO 8601 文本。

\n