上次我在这个博客上写关于时区数据库的文章时，这个数据库正受到一场诉讼的威胁。幸运的是，由于相关公司得到了他们的行为是一个大错误的信息，那起诉讼很快就消失了。不幸的是，这一次的混乱是内部的。
保罗-埃格特是IANA主办的时区数据库的项目负责人，这个职位被称为TZ协调员。 他是这个领域的专家，几十年来一直参与记录时区数据。 不幸的是，他目前无视所有的反对意见，只有他似乎有意采取行动来解决一个只有他认为重要的发明问题。
该数据库是世界上时区信息的主要来源。从操作系统到智能手机，再到JDK等编程语言开发包，都包含了这些数据。虽然你可能从未听说过它，但数据的纯粹普遍性使得变化或损害的潜在影响相当巨大。
时区数据库包含了关于世界上每个地区的时钟如何变化的信息。 这个项目的任务是记录从1970年开始的这些信息。
当然，计算机是这样的，一个返回给定日期的时区的函数可以传入1970年以前的日期和1970年以后的日期。 出于这个原因和完整性的考虑，时区数据库包含1970年以前的数据和1970年以后的数据。 如果你到你的JDK或操作系统中询问1920-01-01的时区偏移，ID为 "Europe/Oslo "或 "Europe/Berlin"，你会得到一个答案。
DateTimeZone oslo = DateTimeZone.forID("Europe/Oslo");
System.out.println(oslo.getOffset(new DateTime(1948, 6, 1, 12, 0))); //prints 3600000
DateTimeZone berlin = DateTimeZone.forID("Europe/Berlin");
System.out.println(berlin.getOffset(new DateTime(1948, 6, 1, 12, 0))); //prints 7200000
建议的改变是将 "Europe/Oslo "降级为 "Europe/Berlin "的别名，理由是由于两个地区在1970年后有相同的数据，所以应该只有一个ID。 这样做的问题是，在1970年以前查询 "Europe/Oslo"（如上），现在将返回柏林的数据，即奥斯陆在1970年以前的良好研究数据将被柏林的数据取代。
Joda-Time的情况更糟糕。 在Joda-Time中，别名（也称为链接）是主动解决的。 在提议的修改之前，这个测试案例通过了，在提议的修改之后，这个测试案例失败了。
assertEquals("Europe/Oslo", DateTimeZone.forID("Europe/Oslo").getID());
换句话说，Joda-Time用户将不可能在内存中保留ID "Europe/Oslo"。 这对于依赖时区管理的系统来说可能是相当灾难性的，特别是那些最终将数据存储在数据库中的系统。 为了在一定程度上缓解这个问题，我已经添加了一个测试案例，并发布了一个包含这样一个测试案例的版本，但显然，没有升级到最新版本的Joda-Time用户如果更新tzdb版本，仍可能看到问题。
但是，向后兼容的问题呢？ 看起来TZ协调员认为这并不重要。 对他来说，用户可能依赖这些数据并不重要。
(技术上来说，这些数据已经移动了，没有被删除。但是，包含被移动的数据的文件通常不会被下游系统使用，因此对所有的意图和目的来说，它已经被删除了）。
你可能会问，为什么柏林比奥斯陆更受青睐？ 为什么柏林可以保持其地位和完整的历史，而奥斯陆却被有效地删除？ 答案是，柏林的人口更多--如果你不在这里读到，你会猜到吗？
从我的角度看，代表挪威的时区ID "Europe/Oslo "被视为不如代表德国的ID "Europe/Berlin "重要，这怎么能不令人难以置信地不公平。是的，有一个围绕1970年和人口的技术原理，但这真的很玄乎。
事实上，它比这更进一步。TZ协调员认为根本不应该有一个奥斯陆/挪威的ID。（官方项目规则说，只应该为1970年后时区数据相同的地方提供一个ID。国家的边界根本不重要）。
建议降级的30个ID中，有 "欧洲/奥斯陆"、"欧洲/斯德哥尔摩"、"欧洲/哥本哈根"、"欧洲/阿姆斯特丹"、"欧洲/卢森堡"、"欧洲/摩纳哥"、"大西洋/雷克雅未克 "和 "印度/马赫"。 如果你经常使用这些ID，你可能会受到这个变化的影响。 冰岛是一个典型的例子--"大西洋/雷克雅未克 "将被降级，而改为 "非洲/阿比让"。如果你知道阿比让在哪个国家，就可以得到奖励。
是什么在推动这一变化？TZ协调员的论点是，如果允许奥斯陆保留其1970年以前的历史，而其他地方（通常在非洲）却不能，这就存在一个公平/公正的问题。我对此有两个问题。首先，我认为柏林可以拥有1970年以前的历史，而奥斯陆却没有，这也是不公平和不平等的。第二，解决公平/公正问题的正确方法是提高水平，而不是降低水平。 也就是说，大多数领导人都希望改善团队中表现较差的人，而不是强迫表现最好的人和最差的人一样差。
因此，我们有一个具有可怕的下游影响的变化，包括一个主要的全球数据集的潜在分叉和破碎的终端用户应用程序，使一个没有人抱怨的问题变得更糟。
我花了几个月的时间试图阻止这种情况的发生，但似乎已经失去了战斗力。尽管邮件列表中几乎所有人都要求暂停这些变化。今晚，30个变化中的9个已经包括在2021b版本中。这些并不是影响欧洲的那些。
我仍然希望能够找到一个让时区协调员满意的解决方案，避免对挪威、瑞典、丹麦或荷兰等国家造成影响。 从中期来看，我希望能够为CLDR项目找到资金，以承担时区数据库的工作（因为CLDR在管理此类数据方面有更好的记录）。
请继续关注，我将努力找出解决这一完全没有必要的问题的最佳方法。
