【问题标题】:Is it safe to store time zone ids in a database or can they change?将时区 ID 存储在数据库中是否安全或可以更改?
【发布时间】:2012-11-09 10:00:14
【问题描述】:

我刚刚开始使用 NodaTime。在我的应用程序中,用户创建一个事件并选择一个时区。无论我使用 BCL (Windows) 时区列表还是 TZDB (Olson) 列表(不要混合使用它们!),我都需要将时区的 id 持久化到我的数据库中,以便以后可以重新创建时区- 感知时间。

鉴于时区 id 似乎有些随意,并且不是 ISO 标准,我是否可以依靠将来调用 GetZoneOrNull 时始终找到该 id?

我假设 GetZoneOrNull 方法是防止这种情况发生的方法;也就是说,当它被传递一个不存在于它自己的 Ids 集合中的 id 时。我的问题是:如果从 Ids 集合中检索到一个 id,我可以相信 GetZoneOrNull 将来永远不会返回 null 吗?

但如果一个 Id 可以从历史中消失,那么最好的应对策略是什么?

【问题讨论】:

    标签: timezone nodatime


    【解决方案1】:

    显然,如果您在 Windows 的时区和 TZDB 之间切换,则时区 ID 会有所不同。 Olson 时区 ID 应该是稳定的,不应更改。尽管我这么说,过去发生了变化,但旧的 Id 仍然存在,并且是新 Id 的别名。所有“地区/城市”ID 都是新样式,并且选择了该方案,以便它们永远不必再次更改。旧的 id 有时会根据时区的合法名称命名,这些名称可能会发生变化。

    我们将时区的 Olson Id 存储在我当前项目的表中。

    我不能说 Windows 时区 ID。

    【讨论】:

    • 我将选择 TZDB 或 Windows,老实说,我倾向于 Olson,以防我需要与外界交流。我喜欢他们将旧 ID 别名为新 ID 的事实,这让我认为问题消失了。我不确定 Windows 是否会采用相同的约定,但您愿意这样认为。由于这个疑问,我将使用奥尔森。谢谢。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-12-29
    • 1970-01-01
    • 2011-01-01
    • 1970-01-01
    相关资源
    最近更新 更多