[tz] tz abbreviations / zdump for programmers

[John Haxby]

On 04/06/12 21:45, Ángel González wrote:
> On 04/06/12 17:02, Boruch Baum wrote:
>> > 2] End users' stubborn insistence on using tz abbreviations
>> > ===========================================================
>> > ... and who can blame them, when that's all they hear in the media.
>> > This leaves me in a bind, because if I accept a tz abbreviation as a
>> > user input, I have two undesirable options: 1) I could scan ALL the
>> > ~420 tzif files for matches and, if I discover that the tz abbrev is
>> > not unique, either make an educated guess (based upon the user's
>> > locale definition which often will include a country code and a
>> > language) or prompt the user for clarification; or 2) I could
>> > pre-compile a list that suits my parochial needs, and update my list
>> > anytime the tzdata package is updated (and still have to occassionally
>> > guess or prompt the user).
> I would ask the user.
>
> Yes, the users are stubborn and will expect "your silly app" to "perfectly
> know" what is, for instance, "PST timezone".
> I'd throw them a dialog requesting clarification if they mean
> -  Pacific Standard Time, UTC−8:00
> -  Pakistan Standard Time, UTC+5:00
> -  Philippine Standard Time, UTC+8:00
>
> Maybe with a "By PST I always mean this one" checkbox.
>
> If you try to guess, you will sometimes "guess wrong", and a smart program
> taking bad decisions is worse than a dumb program you need to guide.
>
> Also, in the example above you will discover that English is official
> language in the three countries... :-)
>

In the US, at least, people have a habit of referring to "PST" as
meaning the time on or near the pacific coast whether or not daylight
savings is in effect.   Mostly it's unambiguous but occasionally it's
confusing.  Sometimes the timezones are referred to as "PT"  (Pacific
Time), "ET" (Eastern Time) and so on.    Allowing people to choose
timezones by their abbreviation is always going to be a minefield.

jch