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

[Robert Elz]

    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