Updated Australian time zone names/strings

Robert Elz kre at munnari.OZ.AU
Sat Apr 7 04:07:13 UTC 2001

    Date:        Fri, 06 Apr 2001 13:08:42 +1000
    From:        Greg Black <gjb at gbch.net>
    Message-ID:  <nospam-986526522.67277 at maxim.gbch.net>

  | I can't force people who write to me (who are often people I
  | don't know) to replace their mail software just because I don't
  | like the dates it generates.

No you can't - nor can you force people to set their clocks correctly so
you can sort mail by date either.   Basically "sort by date" is always going
to get things wrong, for one reason or other, if you want to perform that
kind of sort, you're just going to have to live with that.

  | However, if the TZ data gave the
  | Australian users unambiguous abbreviations for those zones, it
  | would make life easier at little or no cost to anyone.

No it wouldn't.   You can no more force those people sending from one of
the very few mailers that still has that broken behaviour to update their
timezone names than you can get them to update their mailers.   If you
believe that you can get something fixed, it would be far better for
everyone to have the mailers they use fixed so they generate Date headers
that conform to the RFCs, than to try to have them "fixed" via the back
door (by changing the timezone string that the mailer gets handed) so that
they now violate the RFCs (EST is legal in the Date header, AEST is not).

The right way to achieve that is to bug the people who maintain the mailer
in question of course - not those who are merely its users.   If the people
in question (those sending you this broken mail) won't install an updated
version of the mailer they use, then it is unlikely anything that is done is
going to fix the problem for you - at the very least you'd need to wait until
there is yet another change to the AU timezone rules, which might encourage
some people to install updated tzdata files.

  | I don't agree, unless the cost is significant.  As far as I can
  | see, the cost here is nil.

For nil cost you get nil effect.   Something has to change, and someone
has to make that change - that has costs.

  | |   On the other hand, there is another motivation for unambiguous
  | |   abbreviations: it cuts down on human confusion.  This is
  | |   particularly true for Australia, where "EST" can mean one thing for
  | |   time T and a different thing for time T plus 1 second.
  | This is an important point.

Perhaps - whether having the abbreviation the same is better, or
distinct is better, depends entirely upon the application for which
it is to be used.   If you're attempting to parse it, and decide what
offset from UTC it means, then distinct would be better (that's what
sorting broken Date headers requires).   But that isn't a sane thing
to be doing with timezone abbreviations in any case.

For simply specifying a time having them the same works much better,
as you never get odd things like "Sat Apr  7 13:59:33 AEDT 2001"
which would be a date/time/zone combination that simply doesn't
exist.   When it is written as "Sat Apr  7 13:59:33 EST 2001" you
don't even think about the timezone, other than to see "that's the one
that applies where I am" so you simply see ("about 2pm Saturday wall clock

Its the convenience of the latter that makes me think that the choice of
"Summer Time" to go with "Standard Time" was very deliberate, so the
abbreviation would remain the same.


More information about the tz mailing list