Mark Davis ☕ <mark@macchiato.com> writes:
On Tue, Apr 2, 2013 at 7:50 PM, Russ Allbery <rra@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@stanford.edu) <http://www.eyrie.org/~eagle/>