From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug fix for missing years in make_date() |
Date: | 2015-03-31 19:22:39 |
Message-ID: | 20150331192239.GA31163@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 31, 2015 at 12:58:27PM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Tue, Mar 31, 2015 at 10:34:45AM -0400, Adam Brightwell wrote:
> >> Previously, zero was rejected, what does it do now? I'm sure it
> >> represents 0 AD/CE, however, is that important enough to note
> >> given that it was not allowed previously?
>
> > Now, it's supposed to take 0 as 1 BCE, -1 as 2 BCE, etc. There
> > should probably be tests for that.
>
> Surely that is *not* what we want?
It is if we're to be consistent with the rest of the system, to wit:
SELECT to_date('YYYY','0000');
to_date
---------------
0001-01-01 BC
(1 row)
> I'd expect any user-facing date function to reject zero and take -1
> as 1 BC, etc. The behavior you describe is an internal convention,
> not something we want to expose to users.
That ship has already sailed.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-03-31 19:40:17 | Re: clang -fsanitize=undefined error in ecpg |
Previous Message | Tom Lane | 2015-03-31 19:09:34 | Re: Exposing PG_VERSION_NUM in pg_config |