Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’ - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’
Date
Msg-id 1243.1471529346@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’  (Francisco Olarte <folarte@peoplecall.com>)
Responses Re:Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’  (甄明洋 <zhenmingyang@yeah.net>)
List pgsql-bugs
Francisco Olarte <folarte@peoplecall.com> writes:
> On Thu, Aug 18, 2016 at 11:57 AM, 甄明洋 <zhenmingyang@yeah.net> wrote:
>> Why don't use a unified time zone Convention ?

> Given Tom said:
>>> Aren't standards fun?

> I suspect SQL std. mandates it.

The SQL standard does mandate use of ISO convention for timestamp values.
However, the use of any sort of timezone name in "SET timezone" is outside
the SQL standard (or at least it was last I looked).  Our timezone name
support is based on the IANA (nee Olson) timezone data set, which is used
by just about everybody except Microsoft, and that follows the POSIX
standard.

In principle we could hack up the IANA code and data so that zone names
that look like POSIX names follow the ISO sign convention, but if you
ask me that's just nuts.  It would mean for example that "set timezone
to 'PST8PDT'" inside PG would act completely differently from "TZ=PST8PDT"
in the shell.  That would result in more confusion not less.

In short, neither of these choices were made in a vacuum.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’
Next
From: m.overmeyer@yahoo.ca
Date:
Subject: BUG #14289: Potential bug: "invalid attribute number" when dblink result is assigned in PL/PGSQL