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

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

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

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

有人有做类似事情的经验吗？同样，是否有人有我可能错过的精彩选择？

解决方案

我们几乎注定了第一个选项。我们可以为具有时间变更"规则"的国家/地区提前生成日期，但是某些区域没有任何规则，并且更改是通过独裁法令或者每年的立法投票来制定的(巴西一直这样做，直到今年)。

这就是为什么所有OS供应商每年都必须进行一次或者两次时区文件更改的原因，而他们必须这样做，因为它们无法以编程方式生成100％准确的文件。

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

Oracle DBMS会自动为我们处理此问题。日期存储在内部表示形式中(为了方便起见，请想象一下UMT)，并在转换为字符串时根据时区的规则进行格式化。

这也解决了有关随时间变化期间该做什么的争论。 IE。当我们将时钟向后滚动1/2小时时，实际上同一天有2个实例是凌晨3:25.

关于时区规则的最佳信息来源之一是奥尔森数据库，该数据库可从elsie.nci.nih.gov获得。在2008年9月，数据的当前版本是tzdata2008f.tar.gz，代码的当前版本是tzcode2008e.tar.gz(是的，代码不一定总是在数据发布时发布)。这往往是许多其他系统的信息源(尤其是Oracle信息)。也有一个邮件列表。如我们所见，2008年到目前为止，已有六个版本的数据。我的计算机上潜伏着2005r，2006l，2007k的副本，因此情况可能会经常更改。

如今(2017年3月)，可从IANA上获得Olson数据库，请参阅https://iana.org/time-zones和ftp://ftp.iana.org/tz(尤其是ftp://ftp.iana.org/tz /版本)。

还有通用语言环境数据存储库CLDR，它也包含有关时区的信息。