|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Francisco Olarte <folarte(at)peoplecall(dot)com>|
|Cc:||甄明洋 <zhenmingyang(at)yeah(dot)net>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>|
|Subject:||Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’|
|Views:||Raw Message | Whole Thread | Download mbox|
Francisco Olarte <folarte(at)peoplecall(dot)com> writes:
> On Thu, Aug 18, 2016 at 11:57 AM, <zhenmingyang(at)yeah(dot)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
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
|Next Message||m.overmeyer||2016-08-18 17:44:14||BUG #14289: Potential bug: "invalid attribute number" when dblink result is assigned in PL/PGSQL|
|Previous Message||Francisco Olarte||2016-08-18 13:54:36||Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’|