[tz] Ulyanovsk, Altai Krai and Altai republic on their way to change time zones
eggert at cs.ucla.edu
Mon Feb 22 07:40:09 UTC 2016
Matt Johnson (PNP) wrote:
> I assume we will indeed need two separate entries in order to maintain the history. Europe/Ulyanovsk and Europe/Astrakhan?
Yes, that's right.
> Asia/Barnaul seems appropriate for a new zone name?
> We've already applied the Zabaykalsky Krai (Asia/Chita) change in 2016a. We've also already been discussing the creation of Europe/Astrakhan. There are two others still to discuss:
> - Asia/Magadan is moving (in entirety) from UTC+10 to UTC+11
> - Asia/Sakhalin is moving (in entirety) from UTC+10 to UTC+11
As far as I know these two have not gotten through the first reading of the
State Duma yet, and so are more dubious.
To help move this along, I have written a patch to cover the draft changes to
Ulyanovsk Oblast, Altai Krai, and Altai Republic. As these are not yet official
(though they have passed the 1st reading in the State Duma), I'm a bit reluctant
to cut a new release with them. Still, it's OK to put them into the experimental
version on github so I've done that. These changes are over and above the
earlier changes I circulated for Astrakhan, which I've now also pushed to the
As discussed earlier, these draft Russian zones use sign-and-digits names for
their time zone abbreviations, to avoid our inventing these placeholders for
applications that insist on English-language time zone abbreviations even where
there are none. There was a wide variety of opinion about this, ranging from
continuing to invent abbreviations, through long-but-not-invented abbreviations
like "UTC+05:00", to shorter ones like "+0500" and "+05" that are based on ISO
8601. Inventing abbreviations is really not good; we should be recording civil
time, not inventing it. The most popular alternative appeared to be 4-digit
versions like "+0500". I tested both 2-digit and 4-digit versions, and in my
testing 2-digit versions were a bit better, as they have fewer length changes
(e.g., replacing "PET" by "-05" does not change length) and this works better in
old-fashioned applications that (mistakenly) care about abbreviation length.
Another advantage of 2-digit versions is that they work better with the %z
support that is already in zic.c (though we can't use %z in our tables yet, as
we need to give the new zic.c time to percolate out to distributions). So this
latest set of draft changes (attached) continues to use 2-digit abbreviations in
the new zones.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6412 bytes
Desc: not available
More information about the tz