6

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

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

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

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

有没有人有做类似事情的经验？同样，有没有人有任何我可能错过的绝妙选择？

4

4 回答 4

16

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

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

于 2008-09-30T18:42:28.923 回答
4

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

于 2008-09-30T18:45:24.797 回答
2

有关时区规则的最佳信息来源之一是 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-zones和ftp://ftp.iana.org/tz（尤其是ftp://ftp.iana.org/ tz/发布）。

还有 Common Locale Data Repository CLDR，其中也包含有关时区的信息。

于 2008-10-03T02:37:47.390 回答
1

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

这也解决了随着时间的推移在变化期间应该做什么的争论。IE 当您将时钟拨回 1/2 小时时，同一天实际上有 2 个 3:25 am 实例。

于 2008-10-02T10:02:17.097 回答