Not quite there on timezone names in timestamp input
От | Tom Lane |
---|---|
Тема | Not quite there on timezone names in timestamp input |
Дата | |
Msg-id | 13410.1160869338@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Not quite there on timezone names in timestamp input
|
Список | pgsql-hackers |
This doesn't work: regression=# select '2006-07-13 09:20:00 EST5EDT'::timestamptz; ERROR: invalid input syntax for type timestamp with time zone: "2006-07-13 09:20:00 EST5EDT" It never has worked in the past, of course, but I expected it to work in HEAD seeing that the zic database includes EST5EDT as one of the defined zone names (and pg_timezone_names shows it as available). 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 America/Port-au-PrinceGB-EireGMT-0Etc/GMT+8W-SU 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...) 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? regards, tom lane
В списке pgsql-hackers по дате отправления: