解构 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 方法将存储“用户给您的内容”加上推断的偏移量 - 您可以如有必要，可以轻松地使用更高版本的时区数据库更新所有数据。如果您只有计算出的瞬间，则需要先计算出“旧”时区数据库中的原始本地日期/时间，然后再将其调整为“新”时区数据库。这也可能丢失了信息，例如如果输入值曾经不明确（因此您选择了一个或另一个偏移量）但不再是。