<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 April 2013 13:50, Russ Allbery <span dir="ltr"><<a href="mailto:rra@stanford.edu" target="_blank">rra@stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":2kd">Regardless, though, the actual abbreviations used in tzname, etc., aren't<br>
useful for giving the times of recurring meetings. TZ identifiers (which<br>
include US/Pacific, US/Eastern, etc.) certainly are.</div></blockquote></div><br></div><div class="gmail_extra">...and therein lies one major issue.<br><br></div><div class="gmail_extra">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. <b>Note:</b> 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".<br>
<br>On 2 April 2013 14:03, Alan Mintz <span dir="ltr"><<a href="mailto:Alan_Mintz+TZ_IANA@earthlink.net" target="_blank">Alan_Mintz+TZ_IANA@earthlink.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":2tl">
<div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Humans don't need the abbreviation and don't care. They either schedule<br>
the meeting in local time or in the current time in some other time zone<br>
(or possibly in UTC) and then just expect the software to cope with<br>
changes due to daylight saving time. This is a detail of the calendar<br>
exchange format and internal representation, not the user interface.<br>
</blockquote>
<br></div>
I disagree. I think it's natural to want to abbreviate, especially with things that are repeated a lot.</div></blockquote><br>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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>
<br><div class="gmail_extra"><div class="gmail_quote">On 2 April 2013 14:03, Alan Mintz <span dir="ltr"><<a href="mailto:Alan_Mintz+TZ_IANA@earthlink.net" target="_blank">Alan_Mintz+TZ_IANA@earthlink.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":2tl">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).</div></blockquote></div><br></div><div class="gmail_extra">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.<br>
<br>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 <b>within a single country</b> 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.<br>
</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 April 2013 14:03, Mark Davis ☕ <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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 <b>this database serves its
users.</b> 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.<br><br>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 <i>status quo</i> 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.<br>
<br></div><div class="gmail_extra">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.<br></div>
<div class="gmail_extra"><br clear="all"><div>--<br>Tim Parenti<br></div>
</div></div>