On Mon, Feb 15, 2016, at 04:05, Paul Eggert wrote:
Yes, I have the same sense. This is the main argument for having 4 digits in the offset. I also have the sense that 4 digits have been quite a bit more popular in this thread (though I'm not sure how we'd handle Liberia before 1972 -- maybe give up and leave that one alphabetic...).
Is there any way to use 6 digits _if_ the system supports at least seven characters, otherwise use some fallback value? (Maybe "-0044~" - which could be generalized as replacing the sixth and onward character with ~ which can be read as meaning imprecision... or, simply "XXXXXX" if you don't like that.) It'd also be nice to use "UTC+NN:NN" if the system allows at least nine characters, "+NN:NN" [or UTC+NN when there are no minutes] otherwise (and, in Liberia's case, UTC-00:44:30/-00:44:30/-0044~ for 12/9/6 respectively) - perhaps store the most verbose form in the database, and have a defined series of transformations (remove colon, remove trailing :00's if they don't fit, remove UTC/GMT if it doesn't fit, remove colons if they don't fit and we didn't already, etc) based on TZNAME_MAX and a compile-time option for whether POSIX is strictly interpreted to not allow including colons. I also don't understand the objection to using UTC+XX or UTC+XXXX (the latter when there is enough space for it) - if it's really important not to use the term "UTC" for values from before 1961, then use GMT. I absolutely don't understand the objection "any solution we came up with would cause confusion for users wondering why different abbreviations are used before and after 1961." If anyone asks - if anyone even notices anything at all for timezones so far outside the range of what they encounter daily - it can be easily explained to them. I'd also like to note that the example cited in _your_ announcement of the new POSIX feature allowing plus signs in TZ was '<UTC+10>-10'. I also don't think that POSIX's limitation of not allowing a colon in TZ should necessarily be generalized to not allowing a system to provide a colon (or tilde, etc) in a timezone abbreviation set by a non-POSIX-format TZ value. It's a limitation on the format of the TZ environment variable, not the contents of the abbreviation fields (which are set in an implementation-defined manner for TZ=:characters, and unspecified where "either field is less than three bytes (except for the case when dst is missing), more than {TZNAME_MAX} bytes, or if they contain characters other than those specified.") Frankly, I'd be more worried about zones like "EST5EDT", and tz's practice of A) allowing TZ to name a file without a leading colon and B) not giving preference to the POSIX interpretation [so these files would never get hit] when such a file is found. Also, where does "Local time zone must be set--see zic manual page" fit in to this discussion?