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?
Yes.
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.