From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: postgresql@richardneill.org, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17794: dates with zero or negative years are not accepted
In-reply-to: 
 <CAApHDvortAXAenfhKMQSK-xFhu94FOfWFSbt0mm7VC7jtDQhZw@mail.gmail.com>
References: <17794-1ddd1f50f9df08a1@postgresql.org>
 <CAApHDvortAXAenfhKMQSK-xFhu94FOfWFSbt0mm7VC7jtDQhZw@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Thu, 16 Feb 2023 11:06:47 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2137694.1676500618.1@sss.pgh.pa.us>
Date: Wed, 15 Feb 2023 17:36:58 -0500
Message-ID: <2137695.1676500618@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2137695.1676500618%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> From an implementation point of view, it looks trivial to just allow
> 0000 to mean 1 BC, however, the situation is more complex for negative
> numbers as ParseDateTime() sees the negative sign and categorises that
> portion as a timezone. The parsing would have to be adjusted to make
> this be seen as a year, and that'll cause us to suddenly start
> interpreting date strings differently from what we do now, which risks
> breaking applications.  I'm not sure that's worth the risk.

Yeah, the real problem is that getting '-' to be seen as part of the
year field will cause havoc in the parsing rules.  I'd say if you
want this sort of input, use make_date() or make_timestamptz() rather
than going through string form.

			regards, tom lane