On Fri, Sep 18, 2026 at 04:09:39PM +0000, Kacper Kuras wrote:
> > The "agreement between the sender and the receiver" makes it seem we
> > don't need to document that we don't support signs on the years.
>
> Agreement needs each side to state its terms, though, and PostgreSQL
> states its terms in the documentation. It already does for the other
> by-agreement range: ISO 8601 leaves years before 1583 to agreement,
> and B.6 settles them - proleptic Gregorian for all dates - if you
> think to look in an appendix on calendar history. For a leading sign
> there is only B.1's tokenizing rule, "either a numeric time zone or
> a special field", which says nothing about years. So a client finds
> out by trying: -0001-01-02, the wiki's own 2 BC, is refused as
> invalid input syntax, and +10000-01-02 as a time zone displacement.
How about this patch?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 89985ab7b16..dd7af9fda7a 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1879,6 +1879,8 @@ MINUTE TO SECOND
Date and time input is accepted in almost any reasonable format, including
ISO 8601, <acronym>SQL</acronym>-compatible,
traditional <productname>POSTGRES</productname>, and others.
+ (<productname>PostgreSQL</productname> does not support ISO
+ 8601-optional signed years.)
For some formats, ordering of day, month, and year in date input is
ambiguous and there is support for specifying the expected
ordering of these fields. Set the <xref linkend="guc-datestyle"/> parameter
