Sorry, that makes no sense.  How can a timezone ever become invalid?  We do

have old names, where a timezone has had the name we call it by changed - then
we keep the old name forever, for backward compatibility (possibly except for
a case where it existed such a short time with the wrong name that it would
probably never have been used - but I don't think that case has ever arisen.)

Unless Asia/Almaty was always the same as Asia/Novosibirsk and both changed
from UTC+7 to UTC+6 at the same time (having two identical zones is something
that isn't terribly useful, but has happened, and where it is found, we tend
to make one of them just be an alias for the other - just the same as if had
first been called one name and then the other).  But if that's not the case,
and I believe here it isn't, then how would you translate an old timestamp
from Asia/Novosibirsk (from when it was still UTC+7) if the rules you're using
are those for Asia/Almaty which is & was (at the relevant time) UTC+6 ?

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

The link in the GNOME bug goes to

        http://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx

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.

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.

So there's no mapping to correct, other than perhaps a mapping made by Evolution-EWS.

As Tim Parenti asks:

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

The entry in the europe file for Asia/Novosibirsk is

#
# From Paul Eggert (2006-08-19): I'm guessing about Tomsk here; it's
# not clear when it switched from +7 to +6.
# Novosibirskaya oblast', Tomskaya oblast'.
Zone Asia/Novosibirsk    5:31:40 -      LMT     1919 Dec 14 6:00
                         6:00   -       NOVT    1930 Jun 21 # Novosibirsk Time
                         7:00   Russia  NOV%sT  1991 Mar 31 2:00s
                         6:00   Russia  NOV%sT  1992 Jan 19 2:00s
                         7:00   Russia  NOV%sT  1993 May 23 # say Shanks & P.
                         6:00   Russia  NOV%sT  2011 Mar 27 2:00s
                         7:00   -       NOVT

and the entry in the asia file for Asia/Almaty is

# Almaty (formerly Alma-Ata), representing most locations in Kazakhstan
Zone    Asia/Almaty     5:07:48 -       LMT     1924 May  2 # or Alma-Ata
                        5:00    -       ALMT    1930 Jun 21 # Alma-Ata Time
                        6:00 RussiaAsia ALM%sT  1991
                        6:00    -       ALMT    1992
                        6:00 RussiaAsia ALM%sT  2005 Mar 15
                        6:00    -       ALMT

If Microsoft's table is correct to say

        201     N. Central Asia Standard Time   (GMT+06:00) Almaty, Novosibirsk

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.)

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.