【问题标题】:OData Library RTM DateTime InconsistenciesOData 库 RTM 日期时间不一致
【发布时间】:2012-04-11 17:55:43
【问题描述】:

我刚刚升级到 OData 库的 RTM 版本。我注意到 DateTime 处理中似乎存在不一致的地方,并且想知道是否有人可以解释我可能遗漏的内容,或者实际上是否存在一些问题。除了 RTM 库之外,我还依赖于 2012 年 3 月 30 日版本的 MS-ODATA。

MS-ODATA 以以下格式定义 dateTimeUriLiteral(例如简化):

YYYY-MM-DDTHH:MM:SS.NS 其中 NS 定义为 nanoSeconds=1*7DIGIT

MS-ODATA 将 VJsonDateTime 定义为可怕的 /Date(...)/ 格式。

但是,在详细的 JSON 序列化中使用库时,我们会看到 dateTimeUriLiteral 格式,而不是 VJsonDateTime。此外,反序列化仅接受 dateTimeUriLiteral 格式。这看起来像是规范和实现之间的冲突。

此外,dateTimeUriLiteral 不允许时区偏移(例如 ISO 8601 格式的情况)。然而,当序列化的日期时间对象被指定为 DateTimeKind.Utc 时,我们看到库发出一个“Z”终止字符(UTC 的 ISO 8601)。这看起来也像是规范和实现之间的冲突。

此外,当我们使用库反序列化具有终止“Z”的 dateTimeUriLiteral 时 - 反序列化的对象被标记为 DateTimeKind.Local。无论 UTC 指示符是否存在规范问题 WRT 支持,这看起来都不正确。 “Z”应该导致反序列化失败,或者应该导致时间标记为 UTC(非本地)。

【问题讨论】:

标签: datetime odata


【解决方案1】:

详细 JSON V3 使用 ISO DateTime 格式(与 XML 使用的相同)。详细 JSON V2 和 V1 使用 /Date(...)/ 格式。因此,这取决于您正在编写和读取的有效负载版本。

dateTimeUriLiteral 与 Verbose JSON V3 日期时间格式不同。 Verbose JSON V3 中的那个使用 Z(它实际上与您从 XmlConvert.ToString(datetime, XmlDateTimeSerializationMode.RoundtripKind) 获得的相同)。

至于读取“Z”值。这似乎是一个错误。产品团队正在对此进行更详细的研究。可能的解决方法似乎是要么恢复为 V2 格式,要么改用 DateTimeOffset 值(没有这个问题)。

【讨论】:

  • 谢谢 Vitek。我正在使用V3。我在当前规范中没有发现任何说明 Verbose JSON 使用 ISO 格式(带或不带“Z”值)的内容。
  • 网络上的规格可能有点陈旧。该团队目前正在努力重写它们,使其更具可读性,并以易于使用的形式包含所有新功能。不幸的是,这需要一些时间才能完成。新规范作为正在进行中的工作定期发布:github.com/OData/v3ProtocolDocument。随意阅读,如果可能的话发送反馈:-)
猜你喜欢
  • 1970-01-01
  • 2016-08-18
  • 2020-10-04
  • 1970-01-01
  • 2017-12-17
  • 2017-03-31
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多