Skip site navigation (1) Skip section navigation (2)

Re: More time zones

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
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 03:49:30
Message-ID: 26943.1014695370@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> Certainly possible. At the moment the algorithm uses a binary search
> through a fixed size array of choices; reading from a table would
> require changes to a linked list or something else which is not quite as
> fast.

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.

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

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

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?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2002-02-26 03:53:53
Subject: Re: Timezone Inconsistancies
Previous:From: Thomas LockhartDate: 2002-02-26 03:38:52
Subject: Re: More time zones

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group