> That's overstated, but it's a good point nonetheless. We had a report
> of one missing timezone entry (or was it two?). Not sure that that
> should prompt us to add a hundred entries of dubious validity to the
> keyword list.
No one is asking you to add those entries; someone is doing that for
you. Dubious? I've been to some of the places I just updated, and know
for a fact that others exist. And entering something for Easter Island
may get us a lock on the entire Easter Island database community. Same
for all of those other South Pacific Islands. Maybe they'll be so happy
that they'll send plane tickets ;)
> Perhaps we could find some middle ground between a hard-wired list and
> looking up TZ entries in a fully dynamic system table. The list of
> known timezones seems like something we could read from a flat text
> configuration file at startup --- wouldn't that be enough
> configurability?
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.
I'm not sure I fully understand the objections to supporting the current
system until something else demonstrably superior is available. istm
that a database table lookup is the way to internationalize and extend
this area, rather than moving to the "middle ground" of static tables
read at startup. btw, the binary search currently used means that the
cost of having new data is low; I did not double the size of the list
from before.
- Thomas
