On Thu, Oct 13, 2011 at 23:29, Robert Elz <kre@munnari.oz.au> wrote:
 | Forgive me if I'm wrong, but I believe most robust implementations of the TZ
 | database already have some way of expressing an offset in this way.

That isn't the issue.  What is of interest for this topic, is what the
tz database (and code) should put in the tzname[] array &/or tm_zone field
of the struct tm.
...

So, using -04:00 just isn't an option, sorry.

That was precisely my point.  While a numeric offset would be meaningful, it's place is simply not in the abbreviation designation, for programmatic and practical reasons.


On Fri, Oct 14, 2011 at 06:29, Zefram <zefram@fysh.org> wrote:
FWIW, the POSIX standard for $TZ allows ASCII letters (of either case),
digits, "+", and "-" in the abbreviation, and requires the abbreviation
to be at least three characters long.

"LST" seems too like the other "meaningful" identifiers that people may try to continue to infer meaning from it.  Could we perhaps just use the string "local" for these "non-meaningful" cases, and avoid abbreviations altogether?  This all-lowercase string conforms to the POSIX standard as described and would also serve to clearly disambiguate from other identifiers like "UTC", while not having to deal with contrived abbreviations.

--
Tim Parenti