On 2 April 2013 13:50, Russ Allbery <rra@stanford.edu> wrote:
Regardless, though, the actual abbreviations used in tzname, etc., aren't
useful for giving the times of recurring meetings.  TZ identifiers (which
include US/Pacific, US/Eastern, etc.) certainly are.

...and therein lies one major issue.

From a programmatic standpoint, absolutely... use the identifiers internally.  But for any application that uses multiple zones, the humans using the application need some convenient way to refer to these "zones" in their day-to-day lives.  Note: I am intentionally ignoring the differences between notions of what "zone" means here; certainly, it can mean different things to (1) us, (2) those not among us who use time zones regularly, and (3) the "layman".

On 2 April 2013 14:03, Alan Mintz <Alan_Mintz+TZ_IANA@earthlink.net> wrote:
Humans don't need the abbreviation and don't care.  They either schedule
the meeting in local time or in the current time in some other time zone
(or possibly in UTC) and then just expect the software to cope with
changes due to daylight saving time.  This is a detail of the calendar
exchange format and internal representation, not the user interface.

I disagree. I think it's natural to want to abbreviate, especially with things that are repeated a lot.

If I recall correctly, many of those in most vocal opposition to the (A)xST/(A)xDT proposal were the same ones vocally opposed to displaying raw TZ identifiers such as America/New_York to users.  Unfortunately, while computers may not need any textual representation for a time zone, the same cannot be said for humans.  If not abbreviations, then something else... you can't have it both ways.

Arguably, this is the whole reason abbreviations made it into the standard in the first place.  Insisting that users say "11:00 Mytown time" for every city or town they might need is absurd, as there are hundreds or thousands of cities and towns in a given "zone", no matter what notion of "zone" you choose.  We want our technology to be able to communicate effectively with us, and sensible abbreviations are a completely natural and rational way to facilitate this communication by grouping together common times.

On 2 April 2013 14:03, Alan Mintz <Alan_Mintz+TZ_IANA@earthlink.net> wrote:
Like most people, I've lived with the current situation, recognizing that any short TZ abbreviations are potentially ambiguous out of context (i.e. CT can mean US Central time, Central European Time, or Australian Central Time, and probably time in some countries named C*, among others).

Context is everything here.  In most communications, it would be reasonably difficult to get CST confused between America/Chicago, Asia/Shanghai, and Australia/Adelaide, because there is generally some additional context about the country being specified.  The difficulty lies in disambiguating Australia/Adelaide and Australia/Darwin where, during the summer, the same abbreviation refers to two completely different offsets.

I am not making the case for universally unambiguous abbreviations (although that has historically been another proposal), but I don't think it's unreasonable to want these abbreviations within a single country not to be so blatantly ambiguous.  Shifting the onus to individual admins to write patches or conversion scripts serves as an impediment to the very type of communication (that relating to local times) which this database aims to simplify.  Timothy Arceri gave a great example of this.

On 2 April 2013 14:03, Mark Davis ☕ <mark@macchiato.com> wrote:
​ To programmers, the TZ identifiers are what you want to use. To users, that doesn't work well. What one should supply are the customary names and/or abbreviations, so that users understand them.

People on both sides of this argument seem to acknowledge that clear legislation on a federal or multi-state level is practically impossible, so the question comes down to usage.  But regardless of what legislation has (or does not have) to say on the subject, let's not lose sight of the fact that this database serves its users.  Mr Eggert's October 2012 survey clearly showed that (A)xST/(A)xDT is gaining use in Australia.  To me, it is not so much a question of if that balance tips, but when.

While I agree such usage is currently far from consensus, no one here seems to be disputing the general trend.  In addition, while I see much discussion about why we shouldn't worry about abbreviations at all, I see very little about why (A)xST/(A)xDT is substantively worse than xST/xST.  One of the few arguments I have seen for maintaining the status quo indefinitely is poorly-written legacy code.  If that is truly our concern (and I hope it isn't), perhaps we should simply announce such a change well before we actually make it.

If we go forward with this change, those users who care about abbreviations will welcome it.  Those who don't won't even notice.  Perhaps that's the way it should be.

--
Tim Parenti