Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’

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’
Date: 2016-08-18 14:09:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

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

In response to


Browse pgsql-bugs by date

  From Date Subject
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’