Bernd Helmle wrote:
> --On Montag, Februar 25, 2008 14:04:18 -0500 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>
> > The other issue is whether to throw error for year zero, rather than
> > silently interpreting it as 1 BC. I can't recall whether that behavior
> > was intentional at the time, but give
--On Montag, Februar 25, 2008 14:04:18 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
The other issue is whether to throw error for year zero, rather than
silently interpreting it as 1 BC. I can't recall whether that behavior
was intentional at the time, but given our current rather strict
interpre
Bernd Helmle <[EMAIL PROTECTED]> writes:
> I stepped through the code in datetime.c and it seems the culprit here is
> DecodeDate(). It get's the date string from DecodeDateTime(), but without
> the 'BC' century notation. However, it then performs the following check
Yeah, I had just come to the
--On Montag, Februar 25, 2008 12:00:05 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
regression=# select '0001-02-28 BC'::date + 1;
?column?
---
0001-02-29 BC
(1 row)
regression=# select '0002-02-28 BC'::date + 1;
?column?
---
0002-03-01 BC
(1 row)
I stepped throu
Bernd Helmle <[EMAIL PROTECTED]> writes:
> CREATE TABLE foo(datum date);
> INSERT INTO foo VALUES('-02-29');
Since there is no year zero according to Gregorian reckoning, this
should have been rejected to start with.
> INSERT INTO foo VALUES('0001-02-29 BC');
> ERROR: date/time field value o
I saw this strange behavior due to a customer problem who managed to get
dumps which aren't restorable anymore:
CREATE TABLE foo(datum date);
INSERT INTO foo VALUES('-02-29');
INSERT 0 1
SELECT * FROM foo;
datum
---
0001-02-29 BC
(1 row)
COPY foo TO STDOUT;
0001-02-29 BC
