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

[Alan Mintz]

At 2013-04-02 10:08, Russ Allbery wrote:
>Mark Davis ☕ <mark at macchiato.com> writes:
>
> > That works for single points in time. It does not, however, handle
> > repeating meetings. For example:
>
> >   Mondays at 8:00 PT
>
>If you're writing calendaring software, generally you switch to using
>something like the tz identifiers, which give you America/Los_Angeles and
>well-defined behavior.

Personally, when I write "PT", it's meant as a synonym and abbreviation for 
the ruleset represented by "America/Los_Angeles". This is meant to be 
distinct from writing "PST" or "PDT", and used in a context that specifies 
multiple times that fall both inside and outside the DST offset. However, I 
also recognize that this distinction is not obvious, and sometimes use the 
more complex "PST/PDT (UTC-8/7)", which will at least provoke a question if 
not understood. I don't think enough people outside the OS tech world 
recognize most of the tz identifiers to use them in this context. *Maybe* 
with a prefix label like "Time Zone:".

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).

I'd like to see promotion by a standards body of an unambiguous format like 
xxzsT (xx=ISO 3166, Z=intra-country zone abbrev, s={D: DST|S: 
standard|X:non-specific}), but I don't think just doing it with the tz 
database framework will be enough to get it recognized unambiguously.


>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.

--
Alan Mintz <Alan_Mintz+TZ_IANA at Earthlink.net>