Re: Add FET to Default and Europe.txt

On Mon, Oct 8, 2012 at 11:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
>> On 08.10.2012 18:26, Tom Lane wrote:
>>> The other thing that the abbreviation list files are doing for us is
>>> providing a user-configurable way to resolve conflicting abbreviations,
>>> for instance IST (the Indians and the Israelis both use this, but not to
>>> mean the same thing). This requirement isn't ever going to go away.
>
>> Locale-specific abbreviation lists would be nice.
>
> Yeah, that's a good thought, although the lack of standardization of
> locale names seems to make it a bit hard to implement. My first idea
> was "look for a tznames file matching the value of LC_TIME, and if
> found, concatenate its contents with 'Default'". But there are enough
> ways to spell "en_IN" to make that a bit problematic, and besides which
> a user in India might well be running with C locale anyway. Still,
> there might be a useful incremental usability gain there.
>
> We aren't ever going to get out of the need for user configurability
> though. For instance, if a user in India writes "EST", is he thinking
> of the Australian or American meaning? It's plausible that either might
> be preferred, depending on who that user interacts with regularly.

That sounds pretty cool, but "coolness" isn't the right way to
evaluate whether this is good or not.

If we introduce cases where peoples' expectations are liable to be
disappointed (e.g. - they get the wrong EST, and report a bug on
that), then we "lose."

We have, in effect, been treating the handling of time zones in a
manner where we're imagining there's general agreement on their
interpretation. We presently get "bug reports" (and are
"losing"/"getting it not as right as would be nice") in cases where we
leave TZ symbols out, where they could have been included.

The scenario where we could unambiguously include time zones is where
the symbols are unique. If we were to include *all* uniquely-named
symbols, that would minimize the number of complaints about missing
zones, whilst evading the cases where the symbols are non-unique.
That might be worth considering, though it'll certainly attract
complaints in that some odd-ball zones would be included whilst
well-known ones wouldn't.

I would tend to think that local variations (e.g. - having a list for
LC_TIME=en_IN) heads us into a morass of complexity. As you suggest,
two different people using en_IN might have different preferences for
what EST should mean.

That being said, if we had a way to configure preferred localizations,
people could set up their own set of associations. You want your own
morass? You can build it yourself...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"