如何解析Time Zone Information Format扩展版本？64位段与32位段的关系

嘿，这个问题问到点子上了——毕竟涉及到2038年问题的兼容和时区数据的完整性，我来给你梳理清楚：

64位主体是32位主体的数据延续，而非替代。实现64位读取时，你需要同时读取两个主体，不能跳过第一个32位段。原因如下：

• 格式设计的核心目的：32位段的存在是为了兼容旧系统、覆盖到2038年之前的时区规则（包括夏令时转换、偏移量变化等历史数据），而64位段是为了解决32位时间戳的2038年上限问题，扩展时间范围到更遥远的未来。两者是前后衔接的关系，而非替换。

• 官方规范的明确要求：根据tzfile和Tzif的定义，当文件包含双段结构时，程序需要先处理32位段的头部和主体，用于处理UTC 2038年1月19日03:14:07之前的时间；再处理64位段的内容，处理该时间点及之后的时区转换需求。跳过32位段会直接丢失历史时区数据，导致对过去时间的计算完全错误。

• 实际实现的通用做法：像glibc的tzcode这类主流时区处理库，都是同时加载两个段的数据，将32位段的最后一个过渡时间点和64位段的起始规则衔接起来，确保从过去到遥远未来的所有时间点都能正确计算时区偏移和夏令时状态。

举个直观的例子：假设某个时区在2020年有一次夏令时规则调整，2040年又有一次——32位段会包含2020年的调整规则，64位段则包含2040年的规则，只有同时读取两者，才能正确处理2020年和2040年的时区转换。

内容的提问来源于stack exchange，提问作者Mark