UTC 或本地时间与我的架构的区域偏移量？答案

【问题标题】：UTC or local time with zone offset for my schema?UTC 或本地时间与我的架构的区域偏移量？
【发布时间】：2011-01-31 14:34:49
【问题描述】：

我正在为我的 Web 服务定义一个架构，该架构将从多个国家/地区访问。我想知道应该使用以下 2 中的哪一个（根据 xsd dateTime 类型和 ISO 8601 都有效）以及 其中哪一个是 WS-I 兼容的？

UTC 格式，例如 14:15Z 或 14:15:00Z。附加的 Z 字母表示时间以 UTC 表示。
或者，以 [+/-]hh:mm 格式之一使用带有明确区域指定的本地时间。示例：12:15+02:00

【问题讨论】：

标签： java soap xsd timezone utc

【解决方案1】：

这有点主观 - 两者都可以。我更喜欢UTC。无论如何，您可能需要将时间转换为客户端本地时间（并且您应该依赖客户端的信息来执行此操作，因为用户可能从不同的时区登录）。以 UTC 存储时，您不必担心存储如何发生的细节，因为所有时间都表示在同一时区，比较容易（因此排序）。

【讨论】：

+1 您能否详细说明“以 UTC 存储至少可以更快地比较两个日期时间”

【解决方案2】：

这取决于用例。有时了解客户端所在的时区很有用。如果用户在他们的时区中输入 13:00 的时间，他们可能仍然希望在检索日期时看到 13:00。

请注意，我并不是说您将时间存储在本地（当然这会非常糟糕），只是您可能想要维护时区。

【讨论】：

【解决方案3】：

这两种形式都符合 WS-I Basic Profile，因为它们都是 xsd:dateTime 的有效词法格式。

通常，服务描述会在模式中指定 xsd:dateTime，并且通常不会进一步限制词法格式。在这种情况下，服务实现应该准备好处理任何有效的 xsd:dateTime 值，即应该能够处理从客户端接收到的数据中的任何一种形式。

如果您真的愿意，您可以通过定义基于 xsd:dateTime 的自定义类型和附加模式方面来限制服务描述架构中允许的词汇格式。我相信这仍然是符合 WS-I Basic 概要的，但除非您有非常令人信服的理由，否则我会避免这样做。根据我的经验，基于 XSD 类型并添加了模式方面的自定义类型并不总是能很好地与所有 XML 工具集配合使用，因此您可能会通过在 xsd:dateTime 之外添加额外的约束来给客户端带来问题。

【讨论】：