tim at timtimeonline.com
Fri Oct 14 14:11:18 UTC 2011
On Thu, Oct 13, 2011 at 23:29, Robert Elz <kre at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz