Bug fix for missing years in make_date()

2015-03-26 23:26 GMT+01:00 David Fetter <david@fetter.org>:

Folks,

For reasons unclear, dates before the Common Era are disallowed in
make_date(), even though about 2/3 of the underlying data type's range
up until the present time fits that description.

Please find attached a patch fixing same.

+1

Pavel

On 3/26/15 5:26 PM, David Fetter wrote:

+ * Note: Non-positive years are take to be BCE.

s/take/taken/
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Mar 30, 2015 at 05:35:29PM -0500, Jim Nasby wrote:

On 3/26/15 5:26 PM, David Fetter wrote:

+ * Note: Non-positive years are take to be BCE.

s/take/taken/

Good point. Next patch attached.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Good point. Next patch attached.

  /*
- * Note: we'll reject zero or negative year values.  Perhaps negatives
- * should be allowed to represent BC years?
+ * Note: Non-positive years are taken to be BCE.
  */

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?

-Adam

--
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com

On Tue, Mar 31, 2015 at 10:34:45AM -0400, Adam Brightwell wrote:

Good point. Next patch attached.

/*
- * Note: we'll reject zero or negative year values.  Perhaps negatives
- * should be allowed to represent BC years?
+ * Note: Non-positive years are taken to be BCE.
*/

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. The issue here is that zero was
popularized a very long time after the beginning of the Common Era.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

David Fetter <david@fetter.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? 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.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Mar 31, 2015 at 12:58:27PM -0400, Tom Lane wrote:

David Fetter <david@fetter.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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Mar 31, 2015 at 12:22:39PM -0700, David Fetter wrote:

On Tue, Mar 31, 2015 at 12:58:27PM -0400, Tom Lane wrote:

David Fetter <david@fetter.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)

Looking at this further, I think that it should be consistent with
cast rather than with to_date().

SELECT date '0000-01-01';
ERROR: date/time field value out of range: "0000-01-01"
LINE 1: SELECT date '0000-01-01';

Please find attached the next revision of the patch.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate