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. --ado ________________________________________ From: Zefram [zefram@fysh.org] Sent: Wednesday, August 25, 2010 4:48 PM To: tz@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? -zefram