[tz] Australian Timezone Abreviations - Next step

Robert Elz kre at munnari.OZ.AU
Fri Oct 26 09:10:32 UTC 2012


    Date:        Sat, 20 Oct 2012 22:56:39 +1100
    From:        Edwin Groothuis <edwin.groothuis at riverbed.com>
    Message-ID:  <50829177.2080901 at riverbed.com>

  | Consider that there are current issues with the way that the Australian
  | timezones are handled in the TZ data because of its ambiguousness (if
  | such a word exist) with other timezones in the world.

We know they're ambiguous.  They always have been.  There never is, nor
ever has been, any attempt to avoid that.   In fact, the only reason we have
the things at all is because the ancient (US centric) API demanded them
to be present.

  | What is stopping the TZ project from using the unambiguous abbreviations
  | so that the people who use the TZ database in Australia or on Australian
  | services don't run into these basic problems anymore?

It sends the wrong message - suggests that it is rational to use the
abbreviations for some purppose or other, when it isn't.

These things should be (when required) displayed to users, and otherwise
ignored, code that does otherwise is broken.

Hiding the bugs (a little) by making the abbreviations a little less
ambiguous, so the code breaks less often, is 100% the wrong thing to do,
rather when we have the option (which is not all that often) we should
deliberately use ambiguous abbreviations to make erroneous code fail
more often, so it can get fixed sooner.

Attempting to paper around this issue, by altering some abbreviations so
they're not ambiguous is just the same basic approach as the computer
manufacturers who "avoided the problems" with code that referenced *0
by making sure there was valid memory at address 0 that processes could
access, and putting a null byte there, so *0 and "" even had the same
apparent value - as they happened to have on PDP-11's (running unix).

Doing that seemed to avoid problems with lots of broken programs,
but overall it did a big disservice to the community everywhere,
and allowed more & more broken programs to be deployed, rather than
assisting getting the problems fixed.   Only when we got more systems
that refused to go that route, and cause programs containing references
to *0 to break did code authors actually get the message and begin to
fix those bugs.

kre


More information about the tz mailing list