我需要在数据库中存储世界不同地区的夏令时(夏令时)转换规则。我已经有一种存储区域和子区域的方法(所以整个 “澳大利亚的一半”/亚利桑那州/纳瓦霍州 问题已得到解决),但我想知道实现此目的最有效的模式是什么。我看到的两个选项:

  • 拥有一个表,其中包含每年和地区的唯一行,给出夏季时间的开始和结束时间以及特定偏移量
  • 有一个表,存储每个地区的公式和有效日期范围(以色列等地区需要有效范围)

第一个的优点是灵活性,因为从字面上看 任何事物 是可能的。不幸的是,它还需要(a)更多的空间,相应地(b)需要大量的工作来获取数据输入。第二个很好,因为一行可以对应一个区域数十年,但它也需要应用程序层中的某种语言解析器和解释器。由于该数据库将由用没有强大文本处理功能的语言编写的多个不同应用程序使用,因此我宁愿避免这条路线。

我很想只使用 zoneinfo 或类似的东西,但不幸的是,在这种情况下这不是一个选择。同样,我无法标准化日期、时区和夏令时信息 必须 存在于数据库中以满足某些用例。

有人有做类似事情的经验吗?同样,有人有我可能错过的绝妙选择吗?

有帮助吗?

解决方案

你几乎注定会选择第一个选择。对于那些对时间变化有“规则”的国家,您可以根据需要预先生成日期,但有些地区没有任何规则,并且这些变化要么通过独裁法令,要么每年通过立法投票来实施(巴西是这样做的,直到今年)。

这就是为什么所有操作系统供应商每年都会推出一两次时区文件更改——他们必须这样做,因为他们无法以编程方式生成 100% 准确的文件。

其他提示

如果 DST 规则必须位于数据库中,我可能会选择从外部权威来源(图书馆、网站等)自动更新它们。手动维护 DST 规则听起来不太有趣。

有关时区规则的最佳信息来源之一是 Olson 数据库,可从 elsie.nci.nih.gov. 。2008年9月,数据的当前版本是tzdata2008f.tar.gz,代码的当前版本是tzcode2008e.tar.gz(是的,代码并不总是在数据发布时发布)。这往往是许多其他系统的信息来源(特别包括 Oracle 信息)。还有一个可用的邮件列表。正如你所看到的,2008年到目前为止,该数据已经有六个版本;我的机器上潜伏着 2005r、2006l、2007k 的副本,因此情况可能会经常发生变化。

如今(2017 年 3 月),Olson 数据库可从 IANA 获取 — 请参阅 https://iana.org/time-zonesftp://ftp.iana.org/tz (尤其 ftp://ftp.iana.org/tz/releases).

还有通用区域设置数据存储库 CLDR 其中也有有关时区的信息。

Oracle DBMS 自动为您处理这个问题。日期存储在内部表示形式中(为了参数的缘故,让我们想象一下 UMT),并在转换为字符串时根据时区规则进行格式化。

这也解决了关于随着时间的推移发生变化时该做什么的争论。IE。当你将时钟拨回 1/2 小时时,实际上同一天有 2 个凌晨 3:25 的情况。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top