UTC 或本地时间以及我的架构的区域偏移量？
我正在为我的 Web 服务定义一个架构，可以从多个国家/地区访问该架构。我想知道应使用以下 2 项中的哪一项（根据 xsd dateTime 类型和 ISO 8601 两者均有效）以及其中哪一项符合 WS-I 兼容？
- UTC 格式，例如 14:15Z 或 14:15:00Z。附加的 Z 字母表示时间以 UTC 表示。
- 或者，使用 [+/-]hh:mm 格式之一的具有明确区域指定的本地时间。示例：12:15+02:00
I am defining a schema for my web service that will be accessed from multiple countries. I am wondering which of the below 2 should be used (both are valid according to xsd dateTime type and ISO 8601) and which one of them is WS-I compliant?
- UTC format like 14:15Z or 14:15:00Z. The appended Z letter indicates that the time is represented in UTC.
- Alternatively, use a local time with explicit zone designation in one of the formats [+/-]hh:mm. Example: 12:15+02:00
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这有点主观——两者都可以。我更喜欢UTC。无论如何，您可能需要将时间转换为客户端本地时间（并且您应该依赖来自客户端的信息来执行此操作，因为用户可能从不同的时区登录）。当以 UTC 存储时，您不必担心存储如何发生的细节，因为所有时间都在同一时区中表示，并且更容易比较（从而排序）。
It is somewhat subjective - both are OK. I prefer UTC. You likely need to convert the time to client local anyway (and you should rely on information from the client to do so, since the user may login from different timezones). When storing in UTC, you have to worry less about the details of how storage is taking place, since all times are represented in the same timezone and it is much easier to compare (and thus sort).
这取决于用例。有时了解客户端所在的时区很有用。如果用户输入其时区的时间为 13:00，他们可能仍希望在检索日期时看到 13:00。
请注意，我并不是说您将时间存储在本地（这当然会非常糟糕），只是您可能想要维护时区。
It depends on the use case. Sometimes it's useful to know the timezone the client is in. If the user enters a time of 13:00 in their timezone, they probably still want to see 13:00 when the retrieve the date.
Note, I'm not saying you store the time in local (which would be very bad of course), just that you may want to maintain the timezone.
这两种形式都符合 WS-I Basic Profile，因为它们都是 xsd:dateTime 的有效词汇格式。
通常，服务描述会在架构中指定 xsd:dateTime，并且通常不会进一步限制词汇格式。在这种情况下，服务实现应该准备好处理任何有效的 xsd:dateTime 值，即应该能够处理从客户端接收到的数据中的任何一种形式。
如果您确实愿意，可以通过基于 xsd:dateTime 和附加模式方面定义自定义类型来限制服务描述架构中允许的词汇格式。我相信，这仍然符合 WS-I Basic 配置文件，但除非您有非常令人信服的理由，否则我会避免这样做。根据我的经验，基于 XSD 类型并添加了模式方面的自定义类型并不总是能够与所有 XML 工具集很好地配合，因此您可能会通过添加 xsd:dateTime 之外的其他约束来为客户端带来问题。
Both forms compy with WS-I Basic Profile, as they are both valid lexical formats for xsd:dateTime.
Normally, a service description would specify xsd:dateTime in the schema and would not typically constrain the lexical format further. In this case the service implementation should be prepared to handle any valid xsd:dateTime value i.e. should be able to cope with either form in data received from clients.
If you really want to, you could restrict the allowed lexical formats in the schema for your service description, by defining a custom type based on xsd:dateTime with an additional pattern facet. This would still be WS-I Basic profile compliant, I believe, but I would avoid doing this unless you have a very compelling reason. In my experience custom types based on XSD types with added pattern facets do not always play nicely with all XML toolsets, so you may create problems for clients by adding additional constraints beyond xsd:dateTime.