我已阅读 DocumentDB 不支持与日期相关的类型，并将其视为字符串。所以我保存了我的一个属性，例如 2017-01-13T07:30:00+05:30 ，当我尝试在本地读取它时它正在工作，但是一旦我将我的服务托管到天蓝色，它就会转换为 UTC（ 2017-01-13T02:30:00+00:00)。可能是什么原因，我认为我们可以将它们保存并读取为字符串。 DateTimeOffset 序列化是问题吗？
更新
我观察到一件事，当我更改本地系统时区并运行它时，时区正在转换为新时区。所以我怀疑当我们从 DocumentDB 查询数据时，它会将时间转换为运行代码的格式
【问题讨论】：
标签： c# azure azure-cosmosdb
很好很好。这似乎是 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
}
【讨论】：
关于 DateTime，我能给出的最佳建议是使用
CultureInfo.InvariantCulture
适用于 ParseExact 和 ToString，前提是您有确切的格式。
var d = DateTime.Now;
var s1 = d.ToString(CultureInfo.InvariantCulture); // "05/21/2014 22:09:28"
var s2 = d.ToString(new CultureInfo("en-US")); // "5/21/2014 10:09:28 PM"
【讨论】：