Question

我已经读过DocumentDB中不支持与Date相关的类型，它们被认为是字符串。所以我保存了我的一个属性，如2017-01-13T07：30：00 + 05:30，当我尝试在本地读它时它正在工作，但是一旦我将我的服务托管到azure，它就会转换为UTC（ 2017-01-13T02：30：00 + 00：00）。可能是什么原因，我认为我们可以保存并将其作为字符串读取。 DateTimeOffset序列化是问题吗？

更新

我观察到一件事，当我更改本地系统时区并运行它时，时区将转换为新的时区。所以我怀疑当我们从DocumentDB查询数据时，它正在将时间转换为运行代码的格式

Answer 1

非常好。这似乎是DocumentDb如何使用JsonConvert以标准ISO 8601格式反序列化DateTimeOffset字符串的问题。

基本上，他们会将时区转换为本地系统时区，并忽略字符串中的偏移信息。谢谢。这就是DateTimeOffset的重点。对于Azure工作者，那将是UTC。当然，使用您当地的时区进行本地测试并且工作正常（如果原始数据与您的偏移量相同）。

设置JsonConvert.DefaultSettings也没有任何效果，因此它们必须在反序列化时显式设置设置。没有MS，我已经在GITHUB上发了一张票here。

令我困惑的是为什么没有其他人真的在抱怨？这是documentDb的巨大而巨大的错误。我们用它来存储大约8000万个事件;日期相当重要，尤其是当您有夏令时或跨时区时。完全令人抓狂，但是典型的微软。我是粉丝boi！

使用这样的设置应该解决它。因为我们只能通过DefaultSettings（它们被SDK中的显式设置覆盖）来实现这一点，所以我们无能为力。你可能有运气使用JsonConverter，我也在调查。

new JsonSerializerSettings()
        {
            DateTimeZoneHandling = DateTimeZoneHandling.RoundtripKind,
            DateParseHandling = DateParseHandling.DateTimeOffset
        }

Answer 2

特别关注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"

Answer 3

根据Microsoft DateTimeOffset类型数据的通信，他们正在研究的documentdb中存在一些问题。

感谢大家的回复和提示

在DocumentDB

3 个答案: