我读到 DocumentDB 不支持与日期相关的类型，并且将其视为字符串。所以我保存了我的属性之一，例如 2017-01-13T07:30:00+05:30 ，当我尝试在本地读取它时，它正在工作，但是一旦我将我的服务托管到azure，它就会转换为UTC( 2017-01-13T02:30:00+00:00)。可能是什么原因，我认为我们可以将它们保存为字符串并读取它们。 DateTimeOffset 序列化是问题吗？
更新
我观察到一件事，当我更改本地系统时区并运行它时，时区正在转换为新时区。所以我怀疑当我们从 DocumentDB 查询数据时，它会将时间转换为代码运行的格式
最佳答案
好吧好吧。这似乎是 DocumentDb 如何使用 JsonConvert 以标准 ISO 8601 格式反序列化 DateTimeOffset 字符串的问题。
基本上他们会将时区转换为本地系统时区，并忽略字符串中的偏移信息。谢谢。这就是 DateTimeOffset 的要点。对于 Azure 工作人员来说，这将是 UTC。当然，使用您本地的时区进行本地测试并且工作正常(如果原始数据具有与您相同的偏移量)。
设置 JsonConvert.DefaultSettings 也没有效果，因此它们必须在反序列化时显式设置设置。 MS 没有任何消息，我已经在 GITHUB 上提票了 here .
令我困惑的是为什么没有人真正提示？这是 documentDb 的一个巨大的错误。我们用它来存储大约 8000 万个事件；日期相当重要，尤其是当您有夏令时或跨时区时。完全令人抓狂，但却是典型的微软。我是一个粉丝!
使用这样的设置应该可以修复它。由于我们只能通过 DefaultSettings(被 SDK 中的显式设置覆盖)来执行此操作，因此我们无能为力。您可能会幸运地使用 JsonConverter，我也在研究它。
new JsonSerializerSettings()
{
DateTimeZoneHandling = DateTimeZoneHandling.RoundtripKind,
DateParseHandling = DateParseHandling.DateTimeOffset
}
关于c# - 在 DocumentDB 中保存和读取 DateTimeOffset，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41670249/