From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri May 07 2004 - 16:30:38 CDT
From: "Mark Davis" <mark.davis@jtcsv.com>
> That is not a problem. The Olson IDs are not guaranteed to be unique, just
> unambiguous. And there are aliases. Typically these are de-unified for
political
> purposes. Thus you may find that two different IDs produce the same results
over
> the entire period of time in the database.
>
> Moreover, whether or not someone wants to consider two IDs as 'equivalent'
> depends on their timeframe. If I only care about the last 5 years, then many
> more IDs fall into the same equivalence class than if I look over the entire
> period of time covered by Olson.
>
> While I do not believe that the database is perfect, there is no need to
invent
> yet another mechanism.
I do agree. The fact that both "Europe/Istanbul" and "Asia/Istanbul" are
referenced is probably not really political, but it reflects the fact that this
city is on both continents, and that it's timezone covers more than just this
city. Someone leaving on the Asian area near the city, but not in Istanbul must
just wonder why its timezone is not defined in the "Asia" subcategory, and why
he must select it in Europe (the reverse is possible).
So the database aliases one to the other. Aliases are used for timezones that
are compeltely equivalent on the whole timeframe considered (apparently only
starting in the early years of last century). I doubt that before, daylight was
ever applied with consistent rules, when in fact solar time was most frequently
used (with lots of approximations) rather than official times. With solar time,
there's no standard timezone, as each place defines its own time, depending on
seasons and the observed position of the sun in the sky.
What I don't know is if the Riyadh Solar Time is still in use today in Sauda
Arabia (the Olson's database only contains rules for 1987-1989). It may be in
use today for determining the time of religious events, but official time is
probably based on a fixed offset from UTC for practical reasons. If I use the
"Asia/Riyadh89" timezone, it defines the GMTOFF field to 03:07:04 with dayly
changes of daylight offsets up to December 31 (where the daylight offset is
minus 3 minutes). Then after, starting Jan 1st 1990, there's no daylight offset,
so I suppose that it is permanently set now to this GMTOFF value.
But if I consider the comments at the top, there's a astronomical formula to
compute the apparent noon time, rounded to nearest 5 seconds (due to a limit in
the initial Olson implementation).
So a good question remains: should the astronomical formula be used to compute
official time, or should we just keep the average noon time offset 0, and ignore
the Riyadh87 to 89 timezone IDs? The comment at the top is strange as it uses an
number of days from January 0 (What's this??? May be Olson knows or there's a
comment about this in the discussions saved in the HUGE "tzarchive" file).
Also its internal "iso3166.tab" file is obsolete, as well as "zone.tab" which
contains a mapping from countries/territories (with logitude/latitude of a
relevant city) to lists of timezones. As well the "yearistype.sh" script is
quite bogous if used to determine leap years (is it useful or correct for US
election years?).
May be TR35 should specify which parts of the database are referenced.
This archive was generated by hypermail 2.1.5 : Fri May 07 2004 - 18:45:26 CDT