Re: Not quite there on timezone names in timestamp input - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Not quite there on timezone names in timestamp input
Date
Msg-id 25321.1160941682@sss.pgh.pa.us
Whole thread Raw
In response to Re: Not quite there on timezone names in timestamp input  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, Oct 14, 2006 at 07:42:18PM -0400, Tom Lane wrote:
>> On investigation, the problem seems to lie with ParseDateTime(), which
>> is being quite finicky about what it will believe is a timezone name.

> Last time I wrote some code with the zic database, I let it accept
> anything that started with a capital letter, which dropped the posix
> and leaps directories, the zone.tab file, etc.

The trick is not so much where does the TZ name start, as where does it
end.  Also, we have to distinguish dates in the style Oct-15-2006 from
TZ names ... where I believe the code also allows Oct/15/2006 and
Oct.15.2006.

We could probably distinguish the date case by the rules* exactly two separator characters, both alike;* only letters
beforethe first separator, only digits after
 

>> I'd like it to be entirely case insensitive, but am not sure how to make
>> the file lookup work that way.  Thoughts?

> You can't make a file lookup that way. If you want that to work, you
> should preload a list of timezones and store the list internally.

That seems pretty expensive --- not too bad for Unix, in which we could
let backends inherit the list from the postmaster, but in Windows each
backend would have to compute its own list :-(

We could implement our own case-insensitive file search atop a readdir()
scan, but that might just be transferring the expense from one place to
another.  However, we do cache the results of TZ data loads, and most of
the time a backend won't be referencing very many different TZ
definitions over its lifespan, so it might work OK.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Shane Ambler
Date:
Subject: Re: Postgresql Caching
Next
From: Tom Lane
Date:
Subject: Re: Postgresql Caching