[tz] Non-valid timezones, is there a rule to remove them?
fabiano at fidencio.org
Thu Jan 23 10:40:40 UTC 2014
> 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 -
> we keep the old name forever, for backward compatibility (possibly except
> 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
Probably I'm using the wrong term. Let me try to explain with another
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
> that isn't terribly useful, but has happened, and where it is found, we
> to make one of them just be an alias for the other - just the same as if
> first been called one name and then the other). But if that's not the
> 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
> 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
> 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
> 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
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
> 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 &
> 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,
> 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. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz