ISO-8601是否允许时区缩写UTC而不是Z作为时区？
在我参与的几个项目中，我们使用了
YYYY-MM-DDT hh： mm： s UTC
例如
2017-01-01T12:00:00UTC
作为时间格式，并声明它（不正确？）成为ISO-8601的兼容子集。
很明显，ISO-8601包括Z和hhmm，作为指定与UTC的偏移量以及时区的法定方式（忽略夏时制）。
很明显，W3C和大多数采用ISO-8601（子集）的其他组织更喜欢使用Z（和hhmm）。
我正在寻找熟悉或拥有ISO-8601副本的人，以确认使用任何时区缩写是否符合标准，特别是UTC（作为祖鲁时间“Z”的同义词）。
我相信IANA负责时区，ISO-8601使用偏移只是为了避免不得不处理时区变化的问题。
我在这里找到了一个旧版本的标准，它没有提到时区缩写。我想确认在当前标准（ISO-8601:2004？）中使用UTC并声称符合ISO-8601是无效的。
共有1个答案
我有ISO-8601:2004，根据维基百科，这是最新版本。我不认为它允许使用UTC代替Z，尽管它在规范中经常提到“UTC”。
-
我试图用ISO 8601格式解析一个日期，但有些时刻我不清楚。 例如，我有下一个日期：时区。 它是指莫斯科时间07:16还是10:16？我的意思是，我需要增加3个小时的日期或日期已经在莫斯科时间和时区只是显示它与UTC的差异？ P、 我试图找到关于它的信息，但到处都是没有细节的常见格式描述。
-
不，我说的不是时区偏移，而是根据夏令时等因素，一个地区的时区偏移在一年中可能会有所不同。我说的是IANA保持的实际时区。我知道ISO 8601不支持这些，对吗？ 平台正在采取哪些措施来支持在类似 ISO 8601 的字符串表示中标识时区？我注意到最新的Java日期/时间库为此使用了扩展的ISO 8601格式，例如。（请参见日期时间格式化程序 API。 是否有一些融合的约定（例如与其他语言和平台）来
-
问题内容： https://serverfault.com/questions/191331/should-servers-have-their-timezone- set-to-gmt-utc的 后续问题 是将MySQL时区设置为UTC还是将其设置为与服务器或PHP相同的时区？（如果不是UTC） 优缺点都有什么？ 问题答案： 只要您为当前时区设置了正确的时间，知道您存储的datetime列的时区
-
我将Spring Boot与以下对象映射器一起使用: 当OffsetDateTimes被序列化并作为响应返回时，它们的格式如下: 我原以为最后的时区信息应该是这样的: 我在这里缺少或做错了什么，或者无论如何我可以将时区信息序列化为 00 格式而不是 格式？ 非常感谢！
-
利弊何在？
-
我的API使用ISO 8601向客户表示时间。我们有一个功能，我们希望显示它来自哪个时区。通过纯粹存储时区偏移，我们失去了对该细节的跟踪。 即，犹他州和亚利桑那州在一年中的一半时间遵守MST，犹他州在另一半时间切换到MDT。我们目前的解决方案是确定日期是否在夏令时，并在夏令时使用时区，否则使用，但亚利桑那州的ISO 8601日期将导致太平洋夏令时。 有没有办法指定是否以ISO 8601格式观察夏令