<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div>
</div></blockquote><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">Sorry, that makes no sense. How can a timezone ever become invalid? We do</span><br></div>have old names, where a timezone has had the name we call it by changed - then<br>
we keep the old name forever, for backward compatibility (possibly except for<br>a case where it existed such a short time with the wrong name that it would<br>probably never have been used - but I don't think that case has ever arisen.)<br>
</blockquote><div><br></div><div>Probably I'm using the wrong term. Let me try to explain with another example.</div><div>Argentina/San_Juan. IIRC, it has a different timezone than the rest of Argentina for one year or so and then they switched back to the Buenos Aires timezone. So, what I mean by invalid is keep a different name when the differentiation doesn't exist anymore. Even in those cases </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"></div>Unless Asia/Almaty was always the same as Asia/Novosibirsk and both changed<br>
from UTC+7 to UTC+6 at the same time (having two identical zones is something<br>that isn't terribly useful, but has happened, and where it is found, we tend<br>to make one of them just be an alias for the other - just the same as if had<br>
first been called one name and then the other). But if that's not the case,<br>and I believe here it isn't, then how would you translate an old timestamp<br>from Asia/Novosibirsk (from when it was still UTC+7) if the rules you're using<br>
are those for Asia/Almaty which is & was (at the relevant time) UTC+6 ?<br></blockquote><div><br></div><div>Hmmm. I think I got it now. And probably it also answer the question I've asked above.</div></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> This appears to be a problem with some mapping between MSDN and the tz database. If so, I suggest writing to whoever's maintaining that mapping.<br>
<br>
</div>The link in the GNOME bug goes to<br>
<br>
<a href="http://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx</a><br>
<br>
which is *NOT* a mapping between Microsoft's Time Zone Indexes and tz database tzids; it's a list of Time Zone Indexes, names for the zone in question, and time offsets and descriptions of the locale for the zone.<br>
<br>
Some people might take the description of the locale for the name and use it to try to guess the tzid to which it maps, but, as far as I know, Microsoft makes no claim that the "Time" column on the page can be easily mapped to a tzid.<br>
</blockquote><div><br></div><div>Yes, for sure they don't do this.</div><div>Unfortunately we are forced to map to their format, getting the info from libical (which one gets the info from the zone.tab file).</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So there's no mapping to correct, other than perhaps a mapping made by Evolution-EWS.<br></blockquote><div><br></div><div>Yes, and I'm the one trying to do the mapping and getting confused :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As Tim Parenti asks:<br>
<div class="im"><br>
> If the data we have is wrong, that's another matter. We currently have Novosibirsk as observing UTC+7 year-round since March 2011. If they switched back to UTC+6, do you know when they did so, or have any news reports documenting the change?<br>
<br>
</div>The entry in the europe file for Asia/Novosibirsk is<br>
<br>
#<br>
# From Paul Eggert (2006-08-19): I'm guessing about Tomsk here; it's<br>
# not clear when it switched from +7 to +6.<br>
# Novosibirskaya oblast', Tomskaya oblast'.<br>
Zone Asia/Novosibirsk 5:31:40 - LMT 1919 Dec 14 6:00<br>
6:00 - NOVT 1930 Jun 21 # Novosibirsk Time<br>
7:00 Russia NOV%sT 1991 Mar 31 2:00s<br>
6:00 Russia NOV%sT 1992 Jan 19 2:00s<br>
7:00 Russia NOV%sT 1993 May 23 # say Shanks & P.<br>
6:00 Russia NOV%sT 2011 Mar 27 2:00s<br>
7:00 - NOVT<br>
<br>
and the entry in the asia file for Asia/Almaty is<br>
<br>
# Almaty (formerly Alma-Ata), representing most locations in Kazakhstan<br>
Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 # or Alma-Ata<br>
5:00 - ALMT 1930 Jun 21 # Alma-Ata Time<br>
6:00 RussiaAsia ALM%sT 1991<br>
6:00 - ALMT 1992<br>
6:00 RussiaAsia ALM%sT 2005 Mar 15<br>
6:00 - ALMT<br>
<br>
If Microsoft's table is correct to say<br>
<br>
201 N. Central Asia Standard Time (GMT+06:00) Almaty, Novosibirsk<br>
<br>
then the tzdb's Asia/Novosibirsk is wrong and needs to be updated to have a standard-time offset of +6:00, starting at whatever date and time it changed from +7:00. (As Parenti notes, this does *NOT* mean that Asia/Novosibirsk should be made an alias of Asia/Almaty, much less deleted, unless the history of the two zones is known to be identical post-1970 and appears to be identical pre-1970.)</blockquote>
<div><br></div><div>Yeah, I got it and now makes sense to keep both for historical reasons. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If, however, Novosibirsk is 7 hours from GMT and Almaty is 6 hours from GMT, then Microsoft's table is wrong and needs to be updated to separate Almaty and Novosibirsk.</blockquote></div><br>Hmmm. You're right and the only think I can do for now is open a bug in the Microsoft's bugzilla (or equivalent).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I need to thank for all explanations. :-)<br clear="all"><div><br></div><div>Best Regards,</div>-- <br><div>Fabiano Fidêncio</div>
</div></div>