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.
> In particular it won't accept digits as part of the name. That can
> probably be fixed but I'm wondering about the other more or less special
> cases in the timezone name list, such as
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.
> In particular it seems tough to accept GMT-0 as a timezone name without
> breaking recognition of month-name dates such as 'Nov-09-2006'. Any
> thoughts about appropriate heuristics? Should we just accept a few
> cases where we don't recognize zic timezone names? (If so, we'd better
> hack pg_timezone_names to not show those cases...)
The only useful thing I can think of is the the timezones has to be the
last part of the string. If it contains a slash, it's a timezone. Other
than that...
> Another problem here is case folding. The existing code smashes the
> string to initcap format up to the '/' if any, but doesn't fold the part
> after the '/', leaving us with a weird combination of case sensitivity
> and insensitivity, not to mention another reason why EST5EDT won't work.
> 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.
Another way to deal with start timezone names: we have a table for
looking up "EST" and such, short names like GMT-0 could be added to
that table...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.