什么是代表夏令时规则的最佳方式？

Question

我需要在数据库中存储不同世界区域的夏令时（夏令时）转换规则。我已经有了一种存储区域和子区域的方法（因此整个"half of Australia"/Arizona/Navaho问题得到了解决），但我想知道最有效的模式是什么来实现这一目标。我看到的两个选项是：

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

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

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

有没有人有类似的经历？同样，有没有人有任何我可能错过的精彩选择？

Answer 1

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

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

Answer 2

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

Answer 3

关于时区规则的最佳信息来源之一是Olson数据库，该数据库可从elsie.nci.nih.gov获得。在2008年9月，当前版本的数据是tzdata2008f.tar.gz，当前版本的代码是tzcode2008e.tar.gz（是的，当数据出现时代码并不总是被释放）。这往往是许多其他系统（尤其是Oracle信息）的信息来源。还有一个邮件列表。如您所见，到目前为止，2008年已有六个版本的数据;我有潜伏在我的机器上的2005r，2006l，2007k的副本，所以事情可能会经常发生变化。

如今（2017年3月），OANA可以从IANA获取数据库 - 请参阅https://iana.org/time-zones和ftp://ftp.iana.org/tz（尤其是ftp://ftp.iana.org/tz/releases）。

还有Common Locale Data Repository CLDR，它也有关于时区的信息。

Answer 4

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

这也解决了关于在一段时间内改变期间该做什么的争论。 I.E.当你将时钟倒回1/2小时时，实际上有2个实例在同一天凌晨3点25分。