Re: More time zones

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More time zones
Date: 2002-02-26 04:11:05
Message-ID: 3C7B0AD9.9AF348AE@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Binary search doesn't depend on a fixed size table. How about:
> 1. At startup, read & parse TZ config file; build array and sort it.

OK, we could read into a linked list, then transform to a fixed-width
table if nothing else. We'd still get the fast binary search
implementation.

> 2. During keyword lookup, first binary-search the array of fixed
> keywords. If no match, binary-search the TZ array.
> (This assumes that TZ names are not allowed to pre-empt other names,
> such as month names. In some situations the parser might know that
> a TZ name is expected, in which case it could go to the TZ array only,
> thus allowing conflicting names to be resolved.)

Hmm. We'd like to internationalize at the same time, so we may as well
figure out how to hold the same kinds of tokens we have now. And we'd
want to override the built-in entries, so we'd have to do the match on
the external info first, not second.

> > istm that a database table lookup is the way to internationalize and
> > extend this area,
> Um ... in the previous paragraph you were complaining about the
> performance hit of doing a linear search. Which are you more concerned
> about, speed or instant configurability?

Whose complaining? I'm just bringing up the issues, since *someone* is
going to complain no matter what is done. We are going for a consensus
here, even if it is a long road :)

Database table lookups are cached (or can be) to some extent afaik, so
maybe in practice even full database lookups would be relatively cheap
for most applications since they would *tend* to sit on one or a few
time zones.

> This is by no means meant as an attack on the current implementation,
> just a thought that we might be reaching its limits. If the Australians
> want a configurable set of timezone names, why won't other areas?

Australians are the most noticable contingent, having afaik the largest
number of time zones per country in the world. Tuvalu probably wins the
prize for highest number of time zones per-capita; afaicr they have
~6000 residents.

Some other countries have quite a few time zones; Russia had several new
entries in this last update. And the update uncovered one problem zone,
for Lord Howe Island afair. *Their* time zone has an offset of some
hours plus 45 minutes from UTC! So our offset in 10 minute increments
doesn't quite accomodate it. If we moved to quarter-hour offsets or to a
fatter field we would be OK.

Oh, another interesting factoid from the most recent updates: some
places have offsets of 14 hours from UTC! They must be trying to match
up with nearby countries or areas on the same side of the date line...

- Thomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Darcy Buskermolen 2002-02-26 04:45:24 COPY FROM is not 8bit clean
Previous Message Tom Lane 2002-02-26 04:05:23 Re: Timezone Inconsistancies