[tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect
David Patte ₯
dpatte at relativedata.com
Sun Mar 31 01:00:46 UTC 2013
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
> 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.
> 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
> 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.
More information about the tz