Re: IANA timezone abbreviations versus timezone_abbreviations

On Sun Dec 29, 2024 at 11:56 PM CET, Tom Lane wrote:
> Hmm, I don't like your phrasing using "IANA time zone database",
> because that makes it sound like we'll take any abbreviation that's
> found anywhere in that whole data set. What the proposal actually
> does is to recognize any abbreviation that is used, or has been
> used in the past, in the IANA time zone selected by our current
> timezone setting. (And, perhaps more to the point, to give it the
> meaning it has or had in that zone.) Not sure about concise wording
> for that.

Okay, yeah I definitely misunderstood what was happening here. So
scratch my previous attempt at clarifying.

The current situation seems utterly messed up though. One thing that
shocks me is that we're, by default and without warning, parsing IST as
Israel Standard Time instead of the timezone that 17% of the world's
population uses: Indian Standard Time. And even with this patch that
behaviour only changes if you set your timezone to Asia/India. Which
seems suboptimal, because even as a European myself, IST means Indian
Standard Time.

I definitely think this is a step in the right direction, but I'm not
sure that it goes far enough. How about in addition we change the
following:

1. Change the default of timezone_abbreviations to an empty list.
2. When parsing search for the abbreviation string in the IANA timezone
database.
a. If it's a unique match, use that timezone.
b. If it's not unique, but it matches an abbreviation of the current
timezone, use that timezone.
c. If it's part of the timezone_abbreviations list, use that timezone.
d. Else, throw an error.

I think that would result in a lot more sensible behaviour.

Another option would be to put "c" at the top of the list, which would
allow overriding the IANA timezone database with that file. As long as
we don't do that by default I think that would be fine.

And I guess a third option would be to remove conflicts from the Default
timezone_abbreviations list.

To be clear, for backwards compatibility we should probably keep the old
Default list in any of these cases so people can easily switch back in
case this change breaks their application.