Paul G wrote:
What it boils down to is that when it runs out of transitions, python-dateutil selects the "standard" offset and pytz assumes that after the last transition the value "holds".
Neither of these is correct. The correct answer is that the extended-POSIX-TZ string at the end of the file specifies the behaviour following the last explicit transition. If there is no such string, the behaviour is not specified, but it is implied that it's trickier than POSIX can represent, and it is unwise to assume anything. In version 1 of the tzfile format, which didn't have the option of any POSIX-ish-TZ string, the type of local time specified by the last explicit transition applies from then until the end of time, namely 2038-01-19T03:14:08Z. -zefram