我见过很多项目使用epoch格式来表示日期。但据我所知，大多数开发人员使用ISO-8601格式的时间戳。我想知道ISO-8601相对于epoch有什么好处?
我在SO上发现了这个问题，但它更多的是关于正确的日期格式。我知道epoch时间戳通常用于表示上次更新或创建时间——但我认为它更适合于数据库。对我来说，epoch时间戳有点令人困惑，至少因为不同的语言使用不同的时间单位(例如PHP是秒，但Java, Javascript等是毫秒)，而ISO-8601格式是标准的。
br
在凌晨3点调试关键问题时，您希望看到哪个值?
16683294625292022-11-13T08:51:02.529Z
使用ISO 8601文本清晰
关于使用来自某个epoch引用的经过计数来跟踪时间，需要考虑两个问题:
- 各种协议使用各种粒度，如整秒，毫秒，微秒，数百微秒，纳秒等。
- 不同的epoch引用被不同的系统/协议使用。
因此，遇到一个应该表示日期时间的数字可能会有歧义。由于不正确的假设或沟通不畅，这些数字往往容易出错。
一个简单的数字不能被人脑解析为一个时刻。像15687402956或1668329058这样的时间戳对于普通人来说是不可读的。所以调试变得很困难。无效的值可能会被忽略。
通常最好以标准ISO 8601格式的文本形式存储和交换日期-时间值。这个标准定义的格式经过深思熟虑的设计，在人类文化和语言中相对清晰和明确。
零偏移
通常最好报告时刻(时间轴上的特定点)，与utc的偏移量为0小时-分钟-秒，除非你有特殊的理由使用偏移量。
例如，在Java中:
Instant instant = Instant.now() ;
String output = instant.toString() ; // Generates text in ISO 8601 format.
查看此代码运行在Ideone.com。
2022 - 11 - 13 t08:17:31.634762z
位于ISO 8601字符串末尾的Z表示偏移量为0，发音为" Zulu "。
往另一个方向走:
Instant instant = Instant.parse( "2022-11-13T08:17:31.634762Z" ) ;
ZonedDateTimes
请注意，ISO 8601的一个缺点是省略了时区。标准只包含偏移量。
Java中的java.time.ZonedDateTime类明智地扩展了ISO 8601标准，在生成文本时将时区名称附加到括号中。ZonedDateTime相对于OffsetDateTime的最大优点之一是它自动调整时区偏移量(例如，在DST的情况下或当一个国家改变其时区偏移量时)。
ZoneId z = ZoneId.of( "Asia/Tokyo" ) ;
ZonedDateTime now = ZonedDateTime.now( z ) ;
String output = now.toString() ; // ISO 8601 format extended to append the name of the zone in brackets.
当运行在Ideone.com。请注意末尾的正式时区名称(Continent/Region)。
2022 - 11 - 13 - t17:26:08.717876 + 9[亚洲/东京]
希望这种时区表示方式能够作为事实上的标准流行起来，并有一天被添加到官方标准中。
定义offset&时区:
- 抵消仅仅是在UTC时间本初子午线之前或之后的几个小时-分钟-秒。
- A时区是由政治家决定的特定地区人民使用的补偿的过去、现在和未来变化的命名历史。
何时使用count
我唯一会使用计数作为跟踪时间的方式的地方是资源非常有限的地方。毫秒数只占用32位。
在普通的商业应用程序编程中，这样的需求在很大程度上已经消失了。内存很便宜，存储也很便宜。相反，调试是昂贵的，业务沟通错误是昂贵的。因此，尽可能使用ISO 8601文本。