Random832 wrote:
Is there any way to use 6 digits _if_ the system supports at least seven characters, otherwise use some fallback value?
Not in the current tzdata format. The format allows more than 6 characters in the abbreviation, but it doesn't allow for varying formats depending on what the implementation supports. In practice for alignment reasons TZNAME_MAX is typically one less than a power of 2, when it's defined at all. The smallest value I've seen for it recently is 7, which means we would be OK with "+NNNNNN". In pre-2001 POSIX, TZNAME_MAX could be as small as 3, but those systems are obsolete now. This reminds me of another practical argument for brevity. In the current tzdata binary format, the total length of all abbreviations (including the terminating null byte for each one) cannot exceed 50. Currently one zone (Europe/Samara) is already at 49 and I expect that if we use 4-digit abbreviations we'd go over the limit soon. Although we can easily bump the limit to 256 in our own implementation, increasing it past 256 would require a nontrivial format change which would be a big deal. Also, possibly other implementations assume our current TZ_MAX_CHARS value of 50 (a mistake in my view, but there it is).
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
Oh, they'll ask! We get questions about *many* seemingly-minor details like this. And there is benefit to users of a consistent format across the timeline, independent of our not having to answer questions about seemingly-gratuitous changes.
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
True. However, the topics are not entirely separable as we use POSIX-style TZ strings in our binary output files. We can extend our binary-file TZ string format to include colon, but that would be a file format change which would be a cost. In practice my impression is that the colon is omitted more often than it's included and is not worth the hassle here.
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.
This is a different issue. It shouldn't be a problem with the current tzdata distribution, as none of the file names should disagree with the POSIX interpretation in the default installation.
where does "Local time zone must be set--see zic manual page" fit in to this discussion?
It's a grandfathered exception to the Theory guidelines for abbreviations.