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.
signature.asc
Description: Digital signature