[tz] Astrakhan region got approval to change its time zone

[Paul Eggert]

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.