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

[David Patte ₯]

Though Mr Elz makes a compelling argument for ignoring the 
abbreviations, it must be accepted that they indeed are part of the data 
provided in the tz database, and as such we have a responsibility to 
make that portion of the data as usable as possible.

Mr. Arceri's request and explanation makes total sense to me, I totally 
support his reasoning and agree with him 100%.  I recommend that we move 
forward with Mr Arceri's recommendations as soon as possible.


an Mr Arceri's MrOn 2013-03-30 18:37, Robert Elz wrote:
>      Date:        Thu, 28 Mar 2013 02:33:24 +0000 (UTC)
>      From:        Timothy Arceri <t.arceri at bom.gov.au>
>      Message-ID:  <loom.20130328T025054-507 at post.gmane.org>
>
>
>    | The issue is not that the identifiers are not unique worldwide.
>    | The problem is that they are not unique to bordering states in the
>    | same country which run along the same time zone.
>
> The problem is that you're using those absurd abbreviations at all.
> Just stop using the things, and all the problems you're having with
> them will magically go away.
>
> We have to keep them, because they're part of the ancient API designed
> in the US in the early 1970's, a location and time when the things made
> some (local) sense.
>
> The fact that they exist doesn't mean that anyone should use them for
> anything - and anything we can do to dissuade people from using them,
> certainly by not doing anything to make the silly things work better is
> a good thing.
>
> If that API had not been invented, we would not have the the things at all.
>
>    | Most apply daylight savings time, one (Queensland) does not,
>    | this is what causes the confusion. Simply using UTC +10 or UTC +11
>    | is not good enough as the general public has no idea what UTC is.
>
> The general public don't care - they just want to know what time according
> to the clock on the wall things happen - local time - and that's all you
> ever need to tell them.
>
>    | If all states that used EST applied daylight saving then this would be
>    | convenient but as stated above they do not. The problem can be seen in the
>    | delivery example where it would appear an Australian company does
>    | delivery's via time travel.
>
> That's a cute example, but anyone and everyone living anywhere in an
> area where delivery earlier than pickup (apparently) is possible knows
> that "the clocks the other side of the border are different".  People
> in Coolangatta know that the opening times in Tweed Heads are different
> (or could be, Tweed Heads probably mostly uses Qld time, I'd guess).
>
> You see the exact same effect with airline travel - you leave the east
> coast of Aust, fly to the west coast of the US (or even a more extreme
> example, Hawaii) and arrive long before you departed - clock time.  The
> airlines have been dealing with this or a long time now (decades) and they
> have a system that works, and is understood.   Take a look at a flight
> ticket or itinerary, you'll see that the flight leaves Sydney at 15:30
> (or maybe 3:30 pm) and arrives in Los Angeles at 07:30 am (same day).
> (or whatever).   It doesn't say it leaves at 15:30 EST and arrives at
> 07:30 PDT (or anything like that).   Just the time and day.   And somewhere
> it will also note "All times are local".    That is, the 15:30 is the time
> in Sydney when the flight leaves, and the 07:30 is the time in LA when it
> arrives.
>
> No confusion, an amusing time travel experience, and it all just works.
>
>    | So obviously I'm pushing this for my own reason also. We currently use unix
>    | based systems to produce tsunami arrival times for the Australian Tsunami
>    | Warning System.
>
> If you were actually doing what you're suggesting that you're doing then
> you (or your organisation) ought to be prosecuted for criminal negligence
> (or something like that).    That is, you're suggesting that you're going
> to tell people that a Tsunami might arrive at 10:45 EST, and that will
> cause confusion because EST means different things in NSW and Qld.
>
> Really!
>
> What I wold bet that you will really tell people, is that a Tsunami has
> is expected and might arrive at Stradbroke Island at 10:30, Byron Bay at
> 11:38, Noosa at 10:36, Coolangatta at 10:34 Tweed Heads at 11:34 ...
>
> That is, the location in Qld, and in NSW is important for this, a Tsunami
> doesn't arrive (usually) at every point on the coast at the same time.
>
> So, what's the timezone abbreviation for?   If you tell people in to
> expect a Tsunami at 10:34, do you really think that anyone is going to
> wonder what timezone you mean, and perhaps that is 10:34 Perth time???
> Or even 10:34 Sydney time?   If it is arriving at Coolangatta at 10:34
> then it must mean 10:34 local time in Coolangatta.   You also tell people
> it will arrive in Tweed Heads at 11:34 (which in summer is the same absolute
> time of course).
>
>    | This information is displayed on a public webpage (and as described above
>    | cannot use UTC convention). The issue comes into play when listing arrival
>    | times for the east coast of Australia, simply listing all arrival times
>    | as EST will obviously cause confusion especially for towns located near
>    | the border of NSW/QLD where it would appear to take a tsunami an extra hour
>    | to arrive only a couple of kilometres away.
>
> Do you think that when a Tsunami is imminent anyone is going to be caring
> about comparing times - the only people who'd ever care are ones who live
> right there (and so might look up the Coolangatta arrival time even though
> they're in TWeed Heads, or vice versa - though that's probably a little
> unlikely, NSW residents would start in the NSW section, and Qld residents there
> I would think), and the people who live at the border know about the time
> differences.
>
> After the event, when people have time to look at these things and ponder
> the apparent time anomaly, then they also have time to realise that NSW
> has summer time, and Qld does not, and that's why there seems to be an
> hour's difference in the arrival time.
>
>    | Obviously the ideal solution is to fix the EST/CST abbreviations
>
> No, the ideal solution is to stop using them - stop pretending they convey
> any useful meaning.
>
> None of the applications you have mentioned have any business caring about
> time zone abbreviations (or anything other than "local time at xxx") at all.
>
>
> There are applications that do need to deal with timezones, but the
> abbreviations are useless to them - if for no other reason than that the
> lack of any kind of international registry for them means that they cannot
> help but be ambiguous.
>
> You might not care much about the confusion between (Aust) EST and
> North American EST (and others between the different ISTs and JSTs and ...)
> but the people for whom timezone management really does matter do.
> For them, our abbreviations are useless, they either use their own
> identifying system, or numeric offsets - nothing we do can possibly
> solve their problems while simultaneously allowing the abbreviations to
> be used the way you apparently want to use them.
>
> kre
>
>
>


--