[tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect

[Tim Parenti]

On 2 April 2013 13:50, Russ Allbery <rra at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20130402/4e557949/attachment.html