FW: factory zone abbreviation
Olson, Arthur David (NIH/NCI) [E]
olsona at dc37a.nci.nih.gov
Wed Aug 25 21:19:19 UTC 2010
I'm forwarding this message from Zefram, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
From: Zefram [zefram at fysh.org]
Sent: Wednesday, August 25, 2010 4:48 PM
To: tz at lecserver.nci.nih.gov
Subject: factory zone abbreviation
(I'm not on the mailing list. Please CC me on replies.)
The `abbreviation' for the Factory timezone isn't valid for a TZ variable
specification. I have discovered this because I have a tzfile parser
in Perl that follows POSIX rules strictly for the TZ-format rule part,
and I've started applying it systematically to the Olson database.
This is the only zone that it has a problem with.
The POSIX rules for TZ, as described in the Theory file and available
online at <http://www.opengroup.org/onlinepubs/000095399/basedefs/
xbd_chap08.html> among other places, prohibit spaces in the abbreviations.
Factory's abbreviation is a sentence with words separated by spaces.
I see it's grandfathered past zic's test for POSIX validity, but
the intent behind that seems to be more about the length than about
the spaces. I don't have a problem with the length: my code doesn't
impose any fixed length limit. (POSIX allows implementations to limit
the length to six bytes or higher, but doesn't oblige them to.)
You could fix this by changing the spaces to dashes. The result is
POSIX-valid, and also avoids violating the expectations of naive parsers
of date(1) output that expect the timezone abbreviation to be just one
word. The downside is that it slightly impairs readability to humans.
POSIX systems are also still allowed to object to it if they do impose
a small TZNAME_MAX.
What are your thoughts?
More information about the tz