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

Random832 random832 at fastmail.com
Mon Feb 15 15:33:46 UTC 2016

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?

More information about the tz mailing list