[tz] Astrakhan region got approval to change its time zone
eggert at cs.ucla.edu
Mon Feb 15 21:47:59 UTC 2016
> 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
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
> 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.
More information about the tz