我正在更新一个应用程序,以使用NodaTime来解决我们的数据和流程中许多现有的时间问题。
我将需要通过发送IANA时区名称的移动应用解析时区。我需要使用自定义偏移量(即硬编码-04:00)来支持到UTC的转换。我可能也可能不需要支持Windows时区名称。
对于所有这些,我想知道是否需要其他软件包。 TimeZoneConverter和TimeZoneNames如何与NodaTime一起工作?除了NodaTime,我还应该使用其他软件包吗?
我们的最终目标是使所有数据保留为Utc格式,并仅在显示或接受用户输入时转换为用户时间/从用户时间转换为
。答案 0 :(得分:3)
据我所知,在这种情况下,您不需要任何其他软件包。
DateTimeZoneProviders.Tzdb
TzdbDateTimeZoneSource.Default
获取默认的TZDB信息,然后使用WindowsMapping
属性获取可以用于映射的WindowsZones
对象。 TimeZoneConverter
对于最后一个要点很容易使用,但这不是必需的。它提供的IANA ID 应该在Noda Time上正常工作。
TimeZoneNames
是有关向用户显示时区名称的更多信息。如果您不需要这样做,则可能不需要该软件包。
请注意,将所有数据持久化为UTC 可能是一个非常糟糕的主意-如果不了解您的应用程序就很难知道。如果您仅处理过去的值,或者它们是固定时间的瞬间,那很好。但是,如果您允许用户安排将来的事件,那么我将存储用户提供给您的值。这是为什么的例子...
假设用户说他们想在2021年12月1日上午9点安排欧洲/巴黎的活动。如果将其转换为现在的UTC ,则最终结果会是2021-12-01T08 :00Z,因为当前时区规则规定巴黎将于2021年12月位于UTC + 1。
但是,从现在到2021年,法国完全有可能将其时区规则更改为“永久夏令时”,即全年UTC + 2。那时,您的UTC值2021-12-01T08:00Z对应于给定日期巴黎上午10点-与用户指定的相反。
也可以转换为UTC ,这样您就可以创建数据的完全有序视图,只要您保留足够的信息以在每次有新的时区数据时再次执行该转换即可。
就像我说的那样,这可能对您来说不是问题,但是值得一提的是,“始终将所有内容存储在UTC中”的“公认的智慧”对于 all 场景确实不是很好的建议。