[tz] Non-valid timezones, is there a rule to remove them?

[Fabiano Fidêncio]

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

Probably I'm using the wrong term. Let me try to explain with another
example.
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


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

Hmmm. I think I got it now. And probably it also answer the question I've
asked above.

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

Yes, for sure they don't do this.
Unfortunately we are forced to map to their format, getting the info from
libical (which one gets the info from the zone.tab file).


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

Yes, and I'm the one trying to do the mapping and getting confused :-)


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


Yeah, I got it and now makes sense to keep both for historical reasons.


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


Hmmm. You're right and the only think I can do for now is open a bug in the
Microsoft's bugzilla (or equivalent).

I need to thank for all explanations. :-)

Best Regards,
-- 
Fabiano Fidêncio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140123/5f8c6f69/attachment.html>