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

From 甄明洋
Subject Re:Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’
Date
Msg-id 16d276c1.9fb.156a0ceba46.Coremail.zhenmingyang@yeah.net
Whole thread Raw
In response to Re: Re: Re: Re:Re: [BUGS] Re: [BUGS] Return value error of‘to_timestamp’  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
 thanks for you answer
 thanks !



在 2016-08-18 22:09:06,"Tom Lane" <tgl@sss.pgh.pa.us> 写道: >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: Michael Paquier
Date:
Subject: Re: BUG #14243: pg_basebackup failes by a STATUS_DELETE_PENDING file
Next
From: vigneshwaran balaji
Date:
Subject: GTM Server issue