nodatime - 解构 ZonedDateTime

Question

使用 NodaTime，我正在寻找解构 aZonedDateTime以便将其保存到 SQL 数据库中。在我看来，有几个选择。我可以将其解构为InstantandDateTimeZone并将其保存为datetime2and nvarchar(50)。我可以将它解构为DateTimeOffsetandDateTimeZone或LocalDateTimeand DateTimeZone，在任何一种情况下，将它保存为datetimeoffsetand nvarchar(5)。

是否有区别，或者有理由选择一个而不是另一个？

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

我还缺少其他注意事项吗？

标签： nodatime

Answer 1

我建议使用datetimeoffset一个单独的时区 ID。我假设datetimeoffset仍然允许您执行总排序（即即时） - 尽管我认为这可能比您存储一个datetime2. 考虑到它存储更多数据，它也可能在数据库中占用更多空间。

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

如果您要存储未来的日期/时间值，您可能需要考虑的另一件事是，预测的时区偏移量可能会由于规则的变化而发生变化。如果您的原始输入数据是本地日期/时间（如果您正在使用通常是这种情况ZonedDateTime），那么该datetimeoffset方法是存储“用户给您的内容”加上推断的偏移量 - 您可以轻松地更新所有数据如有必要，使用更高版本的时区数据库。如果您只有计算出的瞬间，则需要先计算出“旧”时区数据库中的原始本地日期/时间，然后再将其调整为“新”时区数据库。这也可能丢失了信息，例如，如果输入值曾经是模棱两可的（所以你选择了一个或另一个偏移量）但不再是。