Missing Zones

[andy-shady-org]

Hanoi and Kyiv zone data is missing and causing pytz to break, and in turn django migrations that use tzdata to break

[twschiller]

Looks like #51 and the 2022.2 release might address the Europe/Kiev vs. Europe/Kyiv issue. I don't see Hanoi mentioned in the PR though? What's the expected release date of 2022.2?

StackOverflow discussion of Hanoi: https://stackoverflow.com/a/73333278/402560

[pganssle]

I'm kind of amazed that in 2 days people have managed to pick up 2022b, start using it with pytz, start relying on the existence of Europe/Kyiv and Asia/Hanoi and then try and migrate to zoneinfo (on Windows!)

Be aware that whatever process is relying on this seems likely to be fragile, since it doesn't seem to be accounting for tzdata version differences. Even though I plan to make a tzdata PyPI release today, most people on Linux / Mac shouldn't be sourcing their time zones from this package and many update cycles are longer than 2 days...

[pganssle]

Looks like #51 and the 2022.2 release might address the Europe/Kiev vs. Europe/Kyiv issue. I don't see Hanoi mentioned in the PR though? What's the expected release date of 2022.2?

It seems that Asia/Hanoi is part of backzone, which we've never previously shipped. Apparently pytz started including it in the last day or so. I don't know how many systems distribute PACKRATDATA, so it seems that the 2022.2 release won't fix whatever Asia/Hanoi issue you have, and you'll need to fix it another way.

[pganssle]

I've released version 2022.2, which solves your Europe/Kyiv problem. IIRC correctly it was a deliberate choice to not ship backzone, because most systems won't be shipping backzone, so I think it's unlikely that we'll fix the Asia/Hanoi issue at the moment. Maybe we can have a separate package like tzdata-backzone which adds in the additional data. I am not sure if backzone only includes additional zones (ones that don't differ from any mainstream zone since 1970), or if it also includes dubious data for existing zones. I think it may at least include additional data for zones that, in the mainstream distribution, are links to a mainstream zone, which could cause issues (and I'm not even sure how I'd implement such a thing with the current architecture we have right now).

[andy-shady-org]

Its breaking netbox installs and django packages which is why its being picked up on, netbox-community/netbox#9986

[stub42]

I chose to include backzone in pytz in an attempt to head off problems:

  Changes to past timestamps

    Finish moving to 'backzone' the location-based zones whose
    timestamps since 1970 are duplicates; adjust links accordingly.
    This change ordinarily affects only pre-1970 timestamps, and with
    the new PACKRATLIST option it does not affect any timestamps.
    In this round the affected zones are Antarctica/Vostok,
    Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik,
    Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg,
    Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas,
    Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion,
    Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei,
    Pacific/Wake and Pacific/Wallis, and the affected links are
    Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape,
    Pacific/Truk, and Pacific/Yap.

This upstream change modifies some of the pre-1970 transitions in obscure ways that almost zero users will actually care about and where quite likely dubious in any case. Such as the times pre-1970 when Belfast was not on London time or when Amsterdam switched from being 20 minutes ahead of GMT to GMT. I think I'm going to re-release pytz without backzone, before anyone starts depending on it. Changes to historical timezones has always happened in the upstream database, and normally they are called corrections (which only causes breakage if you area storing wallclock times rather than UTC timestamps).

(and I should look into switching pytz to use tzdata for the database instead of its own copy, in the interests of transitioning to the future)