ISO 8601 夏令时

Question

我的API使用ISO 8601向客户表示时间。我们有一个功能，我们希望显示它来自哪个时区。通过纯粹存储时区偏移，我们失去了对该细节的跟踪。

即，犹他州和亚利桑那州在一年中的一半时间遵守MST-06:00，犹他州在另一半时间切换到MDT-07:00。我们目前的解决方案是确定日期是否在夏令时，并在夏令时使用*DT时区，否则使用*ST，但亚利桑那州的ISO 8601日期将导致太平洋夏令时。

有没有办法指定是否以ISO 8601格式观察夏令时？像2016-01-11T13:00:04Z DST0或类似的东西？

Answer 1

我知道这已经过时了，我希望下面的内容至少能激发对话和想法。

因此，在我看来，这个问题的基础是ISO 8601的问题，它不能携带必要的信息来帮助日光节约转换。

不久前，我遇到了一个类似的问题，并与同事进行了许多“建设性”的对话，讨论如何最好地解决夏令时记录的日期问题，但从没有夏令时的时区来看......我们总是一直回到ISO 8601，他们是解决日期和时间运输的强大力量，但它从未解决过夏令时问题。

结论与许多人最终决定的结论类似，即使用ISO 8601作为偏移量的日期和时间（即使它是无用的），然后提供额外的数据来指示日期和时间所属的时区。这允许客户端渲染提供时区以及 ISO 8601，以提供实际正确的日期和时间，而不管时区如何。

现在，这不是我想离开的地方……事实上，我是讨论中的少数几个人之一，当其他人确信偏移量足够时，我一直在ISO 8601中戳时区漏洞。正如您所发现的，它不允许时区感知或准确转换到其他时区，因此我认为ISO 8601是一种无效的日期和时间时区传输格式。

以下部分是一个笑话，但当您认为它足以工作时，它也很严重…… IOS 8601有严格的格式可遵循，这也是如此，当您正确遵循它时，它就可以毫无瑕疵地工作……

本页提供了格式的细节，以及一些关于行星支持时区的无聊笑话。https://github.com/Gitapedia/AltSO-8601

我还有一个PHP扩展的Carbon类，支持解析和转换Altso 8601格式。https://packagist.org/packages/mossengine/alteredcarbon这个包最好是插入到Carbon包中，但扩展类至少足以证明概念。

看起来可以通过修订来改进ISO 8601格式，但我不能等待那么长时间，觉得偏移量是无用的，可以用时区代替，为什么我们需要所有的冒号和破折号，Ts和Zs，当我们可以将日期和时间连接在一起时，它仍然是可读的，更小，以允许所需的额外字节以提供时区。

下一步是考虑（如果存在）支持短名称时区或发明它们，以便Altso 8601格式可以传输更少量的数据，并具有更深入的日期和时间（特别是时区）。

Answer 2

似乎ISO 8601:2004的新修订版正在准备中，它已被分成两部分，即:“x ”(与当前标准匹配)和“x ”(一个新的部分，处理基本标准的各种扩展，如不确定或未指定的时间，或超过4位数的年份等)。在谷歌上搜索“iso 8601 pdf ”,会出现ISO 8601-1草案和ISO 8601-2草案。由于这些可以追溯到2016年，但ANSI网络商店仍然提供ISO 8601:2004(收费)，它们还不是标准-标准仍然是ISO 8601:2004。

标准和草稿都不允许除了偏离UTC的数字时区之外的任何内容（±1030或±10:30，对于一个虚构的例子）或Z（表示UTC，又名祖鲁时间——因为字母Z在北约音标中被称为祖鲁）。

因此，没有ISO 8601的直接指导。

时区是一个持续有争议的话题，它一点也不简单。例如，2018年2月，佛罗里达州通过了一项立法，规定它将在一年中保持“夏令时”；这是否会被允许还有待观察。IANA托管（但不直接管理）“奥尔森”时区数据库（以其原始创建者奥尔森的名字命名）。您可以在https://www.iana.org/time-zones.找到关于TZDB的信息。该数据库的当前版本可供下载，有两个邮件列表，一个用于公告（一年几次），一个用于正在进行的讨论（大多数时间，通常一天内有多条消息）。Unicode联盟还有CLDR（通用区域设置数据存储库），它也顺便处理时区名称（它也处理区域设置的许多其他方面，它们是它的主要目标，而不是时区）。

即使在亚利桑那州，事情也不简单。亚利桑那州的大部分地区不使用夏令时（夏令时），但纳瓦霍民族确实使用夏令时，除了霍皮族的纳瓦霍民族地区不使用夏令时。即使对时间适用的点进行地理定位也可能无济于事。在有些城市中，两个不同的人口使用与 UTC 不同的时区偏移量，即使两个偏移量没有明显的区域。您几乎必须知道哪个时区应该被视为适用于您正在录制的日期/时间值，并且没有100%可靠的方法来知道这一点。（假设来自加利福尼亚的人在欧洲旅行，并在纽约，伦敦，罗马，悉尼和加尔各答与团队成员安排会议 - 哪个时区适用于会议？

Answer 3

ISO 8601在“时区”和“UTC偏移量”这两个术语之间非常平滑地滑动（并且误导）。

为了引用全局唯一的时刻，像“Thh：mm：ssZ 01：00”这样的表示形式在以下意义上是完美的：

• 它指定UTC刻度上的唯一点，
• 发起人是位于Z01还是DST期间位于Z00是不可知的。

此外，如果您想传达发起者的位置，则可以在8601结构之外附加适当的位置字段。不需要在时间字段中包括位置。

就个人而言，我希望看到“时区”从ISO 8601消失。