Obsolete time zones not recognized anymore

[ilkkao]

After the debian trixie update yesterday it looks like that my django app tests started to error with:

psycopg.errors.InvalidParameterValue: time zone "America/Buenos_Aires" not recognized
psycopg.errors.InvalidParameterValue: time zone "America/Indianapolis" not recognized
psycopg.errors.InvalidParameterValue: time zone "Asia/Ashkhabad" not recognized
psycopg.errors.InvalidParameterValue: time zone "Asia/Chungking" not recognized
psycopg.errors.InvalidParameterValue: time zone "Asia/Macao" not recognized
psycopg.errors.InvalidParameterValue: time zone "Asia/Thimbu" not recognized
psycopg.errors.InvalidParameterValue: time zone "Australia/NSW" not recognized
psycopg.errors.InvalidParameterValue: time zone "Australia/South" not recognized
psycopg.errors.InvalidParameterValue: time zone "Australia/West" not recognized
psycopg.errors.InvalidParameterValue: time zone "Brazil/Acre" not recognized
psycopg.errors.InvalidParameterValue: time zone "Canada/Atlantic" not recognized
psycopg.errors.InvalidParameterValue: time zone "Chile/EasterIsland" not recognized
psycopg.errors.InvalidParameterValue: time zone "Europe/Uzhgorod" not recognized
psycopg.errors.InvalidParameterValue: time zone "Iran" not recognized
psycopg.errors.InvalidParameterValue: time zone "NZ" not recognized
psycopg.errors.InvalidParameterValue: time zone "Pacific/Truk" not recognized
psycopg.errors.InvalidParameterValue: time zone "Singapore" not recognized
psycopg.errors.InvalidParameterValue: time zone "US/Michigan" not recognized

These are old obsolete time zone names that worked until the debian new trixie base image upgraded tzdata.

Just opened this issue as it was a little surprising breaking change as the postgres version didn't change.

I'm also fine if this is just noted as expected side effect.

[gl72]

same here for CET, please follow up ASAP! affected version is 13.21-1.pgdg130+1, last working version reported is 13.21-1.pgdg120+1

[lhotakj]

Please! 🙏

[iccole]

Experienced this with US/Eastern postgres:16. Fixed by pinning to postgres:16-bookworm

[rileythomp]

Same for Asia/Saigon. https://en.wikipedia.org/wiki/List_of_tz_database_time_zones has equivalents for the obsolete timezones.

[haideralipunjabi]

I would love to know if it's a bug or a delibrate change - and if yes, why ?

[yosifkit]

Yes, the image was deliberately changed to Debian Trixie. A breaking change, however minor, was somewhat expected (given the nature of a major OS version bump) and we apologize that it happened.

I'd recommend not using tags without a Debian suite qualifier (-bookworm and -trixie) since then you can control when a major OS version bump happens for you. The plain tags will change again in a few years when Debian Forky is released. We maintain Postgres images on the two most recent releases of Debian so that users have time to migrate.

It is probably something that should be embraced since these are all old obsolete time zone names. If users need to keep them, they can either stick with the -bookworm images (which will continue to be updated) or add the tzdata-legacy package.

[tianon]

Echoing agreement (https://github.com/docker-library/python/issues/1071#issuecomment-3185077167):

Agreed, my understanding is that these aliases have been considered "legacy" and secondary for many years now, and that's finally reflected appropriately in the packaging, and it's trivial for downstream users to either update their aliases or install the additional package, so I don't think we should do so in the base image.

[stavros-k]

What happens when Bookworm becomes EOL? Trixie will be the way to move up. But, even if you update your postgres.conf, your database timezone etc, there is also application side timezone settings. ie an application store in a user table the preferred timezone, Then you select a time from the db using that preferred timezone -- ERROR.

Maybe adding tzdata-legacy in trixie makes sense?

[handicraftsman]

@tianon this makes sense in the Python image, as you usually customize it a lot when building your own application's image.

But with Postgres, it doesn't - because as @stavros-k mentioned, the calling application might be unaware of the change for various reasons, just like Windows 11 + Java 25 are causing this in a Quarkus App pulling Postgres through a dev service ( https://github.com/docker-library/postgres/issues/1392 ).

And nobody wants to customize a not-so-related docker image and store it somewhere just to be able to work on the main tasks.

[handicraftsman]

Additionally, I've seen cases when the application itself deliberately stores user's timezone identifier in a database. Yes, it can be patched with a migration when it comes to Postgres, but if this slips through, it will be a cause for an availability incident.