2

我刚刚升级到 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（非本地）。

4

1 回答 1

2

详细 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 值（没有这个问题）。

于 2012-04-12T08:37:19.080 回答