Problem with zero year

Started by Bruce Momjianabout 17 years ago3 messageshackers
Jump to latest
#1Bruce Momjian
bruce@momjian.us

We added the following commit in 8.4:

/src/backend/utils/adt/datetime.c
tgl
Reject year zero during datetime input, except when it's a 2-digit
year (then it means 2000 AD). Formerly we silently interpreted this
as 1 BC, which at best is unwarranted familiarity with the implementation.
It's barely possible that some app somewhere expects the old behavior,
though, so we won't back-patch this into existing release branches.

The problem is that the 2-digit year check is for <=2 digits, not
exactly two digits:

/*
* When processing a year field, mark it for adjustment if it's only one
* or two digits.
*/
if (*tmask == DTK_M(YEAR))
*is2digits = (flen <= 2);

This leads to some unexpected outputs:

test=> select '1-1-0'::date;
date
------------
2000-01-01

test=> select '1-1-0 BC'::date;
ERROR: date/time field value out of range: "1-1-0 BC"
LINE 1: select '1-1-0 BC'::date;
^

test=> select '1-1-0 AD'::date;
date
------------
2000-01-01

test=> select '1-1-000'::date;
ERROR: date/time field value out of range: "1-1-000"
LINE 1: select '1-1-000'::date;

I think the BC part is fine because that can't possibily be 2000 AD, but
having '0' interpreted as 2000 seems counter to the commit message text;
should the assignment be changed to:

if (*tmask == DTK_M(YEAR))
*is2digits = (flen == 2);

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#1)
Re: Problem with zero year

Bruce Momjian <bruce@momjian.us> writes:

The problem is that the 2-digit year check is for <=2 digits, not
exactly two digits:
...
This leads to some unexpected outputs:

test=> select '1-1-0'::date;
date
------------
2000-01-01

We've interpreted that like that since 7.4, without complaints; and
I think it was an intentional change then (since 7.3 doesn't accept it).
I do not recommend changing it.

regards, tom lane

#3Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#2)
Re: Problem with zero year

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

The problem is that the 2-digit year check is for <=2 digits, not
exactly two digits:
...
This leads to some unexpected outputs:

test=> select '1-1-0'::date;
date
------------
2000-01-01

We've interpreted that like that since 7.4, without complaints; and
I think it was an intentional change then (since 7.3 doesn't accept it).
I do not recommend changing it.

OK, the release note text will be:

Reject year '0 BC' and years '000' and '0000' (Tom)

Previously these were interpreted as 1 BC.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +