[tz] Ulyanovsk, Altai Krai and Altai republic on their way to change time zones

Paul Eggert 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 
experimental version.

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...
Name: 0001-New-zones-Europe-Ulyanovsk-and-Asia-Barnaul.patch
Type: text/x-diff
Size: 6412 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20160221/c526f021/0001-New-zones-Europe-Ulyanovsk-and-Asia-Barnaul.patch>

More information about the tz mailing list