ZoneInfo在遥远的将来如何处理DST？

Question

我试图了解zoneinfo模块是如何在遥远的将来计算出夏令时转换的，而dateutil和pytz似乎都放弃了夏时制转换。

我知道这些转换在未来并不是真正有意义的，但这种不一致可能是一个问题，也是造成混乱的根源。

import datetime
import zoneinfo
import pytz
from dateutil.tz import gettz as dateutil_gettz

eastern_zone = zoneinfo.ZoneInfo('America/New_York')
eastern_pytz = pytz.timezone('America/New_York')
eastern_dateutil = dateutil_gettz('America/New_York')

dates_7000 = [datetime.datetime(7000, month, 1) for month in range(1, 13)]
dates_7000_zone = [d.replace(tzinfo=eastern_zone) for d in dates_7000]
dates_7000_pytz = [eastern_pytz.localize(d) for d in dates_7000]
dates_7000_dateutil = [d.replace(tzinfo=eastern_dateutil) for d in dates_7000]

# for zoneinfo, there are two utcoffsets in this set
# datetime.timedelta(days=-1, seconds=68400)
# datetime.timedelta(days=-1, seconds=72000)
{d.utcoffset() for d in dates_7000_zone}

# for pytz and dateutil there is only one
# datetime.timedelta(days=-1, seconds=68400)
{d.utcoffset() for d in dates_7000_pytz}
{d.utcoffset() for d in dates_7000_dateutil}

我相信zoneinfo只是在无限期地推进最后的规则。是否有办法弄清楚这个规则是什么，然后创建一个pytz或dateutil时区来遵循它呢？

Answer 1

与dateutil.tz和pytz不同，zoneinfo模块能够解析版本3的TZif文件，而版本3可能包含一个描述DST转换的循环规则的页脚 (通常为do)。zoneinfo实现中与这些基于规则的转换相关的部分可以找到这里。这种能力之所以重要，有几个原因：

1. 版本1的TZif文件将转换时间存储为来自Unix的32位偏移，因此受启示约束。现在，2038年是在遥远的未来，但在16年后，它将是现在，它将不可能表达新的转换使用版本1文件。
2. tz项目同时提供了" fat“和"slim”二进制文件-fat二进制文件包括一些相当长的年份的硬编码转换，甚至对于具有简单的基于规则的偏移量的区域也是如此，但是“瘦”二进制文件存储准确描述该区域所需的最小过渡时间。这意味着对于具有基于规则的转换的区域，版本1的文件在过去会被截断，而dateutil.tz和pytz甚至不会在当前的日期时间中工作。一些发行版已经尝试从fat转换为瘦二进制文件，但是由于对版本3文件的不完全支持而被咬了。据推测，当达到某种阈值时，它们都将过渡到瘦文件，因为没有什么特别的理由不这样做，而且需要发送更少的数据。

当然，我在这里的正常免责声明也适用(你已经清楚地内化了，但它值得重复)：在1970年到今天这段时间内，可用的时区数据是正确的，而且离这段时间越远，你就会走向任何一个方向(过去或未来)，数据就越没有意义。即使是在不久的将来，zoneinfo也向您展示了tz项目维护人员在什么时候将处于不同的区域的最佳猜测，而且随着您深入到未来，这些猜测就变得不那么准确了。