Subject: VTIMEZONE duplicate entries

From: [email-masked]
Date: Mon, 24 Apr 2000 16:16:17 -0400

Hi all, I've been reading the emails on duplicate timezone entries in the
database.  My area of concern is with applications searching this database
for a particular timezone.  If we don't adhere to stricked rules limiting
duplicate records, I'm concerned that this database could get quite large.
I realize that our limitations and obligations are to the governing bodies
of each country and what they preceive as their timezones which do require
multiple entries for certain areas which we must account for but I feel we
should not freely create duplicates.

So, let's see if we can come up with the smallest set of timezones that
accurately represent the world's current timezones for a first pass.

Ok...

---

From: Doug Royer <[email-masked]>
Date: Mon, 24 Apr 2000 12:51:48 -0700

> accurately represent the world's current timezones for a first pass.

DATA - Yes - let't not duplicate the data - I think this is your point?

Converting the data is one of the steps. I do not see any reason
to restrict what is converted. Once the data is converted any
client could ask for only what it wanted. Any server could select
what it would serve.

It is a bit more complicated than that. If a servers intent was only
to hold VTIMEZONE data for 1970 -> current date/time. It must provide
more than one standardc and daylightc per VTIMEZONE to account for
any changes over time for a given timezone. Also the format of the
earliest VTIMEZONE can't be cut down simply because it started in 1969.
If it did then it would pollute the registered name of that timezone.

So a VTIEMZONE server would have some choices:

	(a) Return the TZID without the prefix - tzidprefix, and
	    with a restricted set of data (1970->current). As the TZID
	    with tzidprefix is the official set of data
	   (tzidpreifx == full data).

	(b) Say 'NO' the VTIMEZONE registered name you asked for
	    spans more time that that.
		
I would envision a future TZ-server to be asked for one or more of:

	Current VTIMEZONE given a location
	(perhaps lat/lon or name of place)

	Any VTIMEZONE with a TZNAME, TZID, or TZALIAS of <some-string>.

	Restrict the results to a date/time range. So you could
	find the correct VTIMEZONE for Phoenix AZ on Dec 1st 1971.
	With the client aware that it might get a non official result
	with stripped down data and a TZID without a tzidprefix.

And of course it would assume the results were in the database.

-Doug