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

Russ Allbery rra at stanford.edu
Tue Apr 2 18:19:47 UTC 2013


Mark Davis ☕ <mark at macchiato.com> writes:
> On Tue, Apr 2, 2013 at 7:50 PM, Russ Allbery <rra at stanford.edu> wrote:

>> Regardless, though, the actual abbreviations used in tzname, etc.,
>> aren't useful for giving the times of recurring meetings.  TZ
>> identifiers (which include US/Pacific, US/Eastern, etc.) certainly are.

> ​To programmers, the TZ identifiers are what you want to use. To users,
> that doesn't work well. What one should supply are the customary names
> and/or abbreviations, so that users understand them.

Sure, this is just an alternate version of the time zone selection
problem, which has been much-discussed.

But my point is that the specific abbreviations that are put into tzname
are worthless for this purpose because they change based on whether it's
currently daylight saving time, which is exactly what you don't want for
recurring meetings.  You don't want to schedule a meeting in PST; at best,
that leaves things badly undefined when daylight saving time comes.  Does
the meeting move or not?

In other words, you want some sort of identifier for the time *zone*
(whether that be America/Los_Angeles or US/Pacific or PST8PDT or PT or
whatever the user understands), not for the current time *offset*.  And
the latter is what you get from tzname and %Z.  If you want to represent
the *offset*, that's where numeric identifiers like -0800 are the best
approach.

As kre says, the time offset abbreviations in tzname, et al., are a bad
solution to the wrong problem.

(Ironically, the current Australian abbreviations are marginally *more*
useful than most of the abbreviations because they *don't* change based on
daylight saving time, but of course that's yet another thing people are
unhappy about.)

I think all the people who are arguing in favor of time offset
abbreviations should have the experience I had of writing software that
cares greatly about the exact time of things and uses a protocol where
using the abbreviations was previously widespread.  (In my case, it was
writing Usenet software.)  After you spend some time dealing with this
sort of nonsense:

/* Additional non-numeric time zones supported because the old parsedate
   parser supported them.  These aren't legal in RFC 5322, but are supported
   in lax mode. */
static const struct {
    const char name[5];
    long offset;
} OBS_ZONE_OFFSET[] = {
    { "UTC",    0 },                 /* Universal Coordinated */
    { "CUT",    0 },                 /* Coordinated Universal */
    { "WET",    0 },                 /* Western European */
    { "BST",    1 * 60 * 60 },       /* British Summer */
    { "NDT",  (-2 * 60 + 30) * 60 }, /* Newfoundland Daylight */
    { "NST",  (-3 * 60 + 30) * 60 }, /* Newfoundland Standard */
    { "ADT",   -3 * 60 * 60 },       /* Atlantic Daylight */
    { "AST",   -4 * 60 * 60 },       /* Atlantic Standard */
    { "YDT",   -8 * 60 * 60 },       /* Yukon Daylight */
    { "YST",   -9 * 60 * 60 },       /* Yukon Standard */
    { "AKDT",  -8 * 60 * 60 },       /* Alaska Daylight */
    { "AKST",  -9 * 60 * 60 },       /* Alaska Standard */
    /* ... */
};

you realize just how obnoxious the abbreviations are, how many cases
you're still not handling, why this whole approach is doomed, and why
every software that identifies time zone offsets (as opposed to zone
names) should just use ISO 8601 and be done with it.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the tz mailing list