What about time zones like Tehran (GMT+3:30), Kabul (GMT+4:30), Katmandu (GMT+5:45) and other non-cardinal-hour GMT offsets? Is this handled in some *documented* way already? -- Brandon Aiken CS/IT Systems Engineer -----Original Message----- From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Tom Lane Sent: Monday, October 16, 2006 6:06 PM To: pgsql-hackers@xxxxxxxxxxxxxx; pgsql-general@xxxxxxxxxxxxxx Subject: [GENERAL] Anyone using "POSIX" time zone offset capability? While trying to clean up ParseDateTime so it works reliably with full timezone names, I found out about a "feature" that so far as I can tell has never been documented except in comments in datetime.c. The datetime input code tries to recognize what it calls "POSIX time zones", which are timezone abbreviations followed by an additional hour/minute offset: /* DecodePosixTimezone() * Interpret string as a POSIX-compatible timezone: * PST-hh:mm * PST+h * PST * - thomas 2000-03-15 However this doesn't actually work in all cases: regression=# select '12:34:00 PDT+00:30'::timetz; timetz ---------------- 12:34:00-07:30 (1 row) regression=# select '12:34:00 PDT-00:30'::timetz; ERROR: invalid input syntax for type time with time zone: "12:34:00 PDT-00:30" (The behavior varies depending on which PG release you try it with, but I can't find any that produce the expected result for a negative fractional-hour offset.) This syntax is ambiguous against some full timezone names present in the zic database, such as "GMT+0", and it's also responsible for a number of really ugly special cases in the datetime parser. In view of the fact that it's never entirely worked and never been documented, I'm inclined to take it out. Comments? Is anyone actually using this? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
