解构ZonedDateTime

Question

使用NodaTime，我希望解构一个ZonedDateTime，以便将它保存到一个SQL数据库中。在我看来有几个选择。我可以将其解构为Instant和DateTimeZone，并将其保存为datetime2和nvarchar(50)。我可以将其解构为DateTimeOffset和DateTimeZone或LocalDateTime和DateTimeZone，并将其保存为datetimeoffset和nvarchar(5)。

有什么不同，或者有理由选择一个而不是另一个？

我唯一能想到的是，如果数据库被一个没有像datetimeoffset那样健壮的时区->偏移转换系统的服务读取，那么nvarchar(50) + NodaTime可能会更好。在这种情况下，我至少已经捕获了偏移量，在那个时区，在那个时区，使用datetime2 + nvarchar(50)方法丢失了偏移量(或者需要从历史时区信息重新计算)。

我还有其他的考虑吗？

Answer 1

我建议使用datetimeoffset和单独的时区ID。我假设datetimeoffset仍然允许您执行全面排序(即即时排序)--尽管我认为这可能比存储datetime2的效率要低。考虑到它存储的数据更多，它也很可能在数据库中占用更多的空间。

即使数据库被具有时区转换操作的服务读取，在数据库中存储偏移量也允许您根据本地日期对数据执行查询。“让我看看星期二所有的约会”。如果您只有实例，则不能执行纯数据库端的查询。

如果要存储未来的日期/时间值，您可能需要考虑的另一件事是，由于规则的更改，预测的时区偏移量可能会发生变化。如果您的原始输入数据是本地日期/时间(如果您正在使用ZonedDateTime，通常是这样)，那么datetimeoffset方法将存储“用户给您的东西”以及推断的偏移量--如果有必要，您可以轻松地用更高版本的时区数据库更新所有数据。如果只有计算的瞬间，则在将其调整为“新”时区数据库之前，需要计算出“旧”时区数据库中的原始本地日期/时间。这也可能丢失了信息，例如，如果输入值过去是不明确的(因此您选择了一个偏移量或另一个偏移量)，但现在不再是这样了。