<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>In addition to the 2016 change, it looks like both of the new zones also have differing history (other than LMT) from the zones they were split from. Was this intentional?<div><br></div><div>Europe/Ulyanovsk should be the same as Europe/Moscow before 2016, but looks like they also deviate before 1991. Where do the 1989 and 1930 entry for Ulyanovsk come from?</div><div><br></div><div>Asia/Barnaul should be the same as Asia/Omsk before 2016, but looks like they also deviate considerably before that. Looks like rule Russia is on the wrong lines, Omsk has an extra 2011 entry that Barnaul doesn't, and the offsets differ as well.</div><div><br></div><div>Am I mistaken, or are there errors in the proposed changes? Or are there additional sources to be cited?</div><div><br></div><div>Thanks,</div><div>-Matt<br><br><div>> To: matt.johnson@microsoft.com; tz@iana.org<br>> From: eggert@cs.ucla.edu<br>> Date: Sun, 21 Feb 2016 23:40:09 -0800<br>> Subject: Re: [tz] Ulyanovsk, Altai Krai and Altai republic on their way to change time zones<br>> <br>> Matt Johnson (PNP) wrote:<br>> > I assume we will indeed need two separate entries in order to maintain the history. Europe/Ulyanovsk and Europe/Astrakhan?<br>> <br>> Yes, that's right.<br>> <br>> > Asia/Barnaul seems appropriate for a new zone name?<br>> <br>> Yes.<br>> <br>> > 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:<br>> ><br>> > - Asia/Magadan is moving (in entirety) from UTC+10 to UTC+11<br>> ><br>> > - Asia/Sakhalin is moving (in entirety) from UTC+10 to UTC+11<br>> <br>> As far as I know these two have not gotten through the first reading of the <br>> State Duma yet, and so are more dubious.<br>> <br>> To help move this along, I have written a patch to cover the draft changes to <br>> Ulyanovsk Oblast, Altai Krai, and Altai Republic. As these are not yet official <br>> (though they have passed the 1st reading in the State Duma), I'm a bit reluctant <br>> to cut a new release with them. Still, it's OK to put them into the experimental <br>> version on github so I've done that. These changes are over and above the <br>> earlier changes I circulated for Astrakhan, which I've now also pushed to the <br>> experimental version.<br>> <br>> As discussed earlier, these draft Russian zones use sign-and-digits names for <br>> their time zone abbreviations, to avoid our inventing these placeholders for <br>> applications that insist on English-language time zone abbreviations even where <br>> there are none. There was a wide variety of opinion about this, ranging from <br>> continuing to invent abbreviations, through long-but-not-invented abbreviations <br>> like "UTC+05:00", to shorter ones like "+0500" and "+05" that are based on ISO <br>> 8601. Inventing abbreviations is really not good; we should be recording civil <br>> time, not inventing it. The most popular alternative appeared to be 4-digit <br>> versions like "+0500". I tested both 2-digit and 4-digit versions, and in my <br>> testing 2-digit versions were a bit better, as they have fewer length changes <br>> (e.g., replacing "PET" by "-05" does not change length) and this works better in <br>> old-fashioned applications that (mistakenly) care about abbreviation length. <br>> Another advantage of 2-digit versions is that they work better with the %z <br>> support that is already in zic.c (though we can't use %z in our tables yet, as <br>> we need to give the new zic.c time to percolate out to distributions). So this <br>> latest set of draft changes (attached) continues to use 2-digit abbreviations in <br>> the new zones.<br></div></div> </div></body>
</html>