我们开发并维护一个已在丹麦使用了几年的预订系统。
但是，我们现在正扩展到一个时区以外的国家，一些客户将拥有一个跨越多个时区的系统。 因此，我们天真的DateTime方法将来可能会给我们带来问题。 我喜欢NodaTime方法，该方法针对特定目的使用特定类，这将使我们的开发人员更容易学习。
然而，我们节省的一件事是特定餐厅特定预订的到达时间。 对我而言，这听起来像我将使用LocalDateTime，这确保即使是坐在具有不同时区的计算机上的经理仍然会看到正确的到达时间（相对于餐厅的TimeZone的时间，没有我们因为没有使用时区，所以必须考虑时区。
如果在某些时候我们想在用户本地的不同时区显示这些时间（对我而言当时没有意义），我们可以通过使用餐厅的TimeZone来计算，然后计算相对时间
使用的正确类是否为LocalDateTime，在SQLServer中保存为日期时间？
是否有任何论据应该让我们考虑ZonedDateTime这样的用例？
答案 0 :(得分：3)
如果您始终知道与当地预订日期/时间相关的时区，那大部分都可以。据推测，时区与预订的餐厅有关。
您可能遇到的一个问题是，LocalDateTime和DateTimeZone对并非始终明确确定及时。如果您的餐厅营业至深夜，并且您从夏季到冬季时间凌晨2点（凌晨1点），那么上午1点15分的预订实际上可能比凌晨1点45分的预订要晚。这就是ZonedDateTime包含LocalDateTime，DateTimeZone引用和Offset来解决歧义的原因。
此外，仅使用LocalDateTime可能会使执行某些查询变得更加棘手 - 如果您希望将预订按其实际排序顺序排列，则需要将其解析为ZonedDateTime值。但也许你不需要那些查询。
从根本上说，您应该可以为任何预订提供LocalDateTime和DateTimeZone - 并考虑如何解决歧义（或跳过时间，从冬季到夏季）。如果您有这方面的信息/政策，那很好。