Re: 8.5.1. Date/Time Input

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Kacper Kuras <kacperkuras(at)hotmail(dot)com>
Cc: "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: 8.5.1. Date/Time Input
Date: 2026-09-18 15:48:53
Message-ID: aq1dZXAGxsprFQZ-@momjian.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Fri, Sep 18, 2026 at 02:50:20PM +0000, Kacper Kuras wrote:
> Thanks. In the patch, "without a sign" only holds for years after
> 9999: dropping the minus from -0001-01-02 gives 0001-01-02, which is
> 1 AD, not 2 BC. Perhaps:
>
> (ISO 8601 writes years after 9999 with a leading plus sign, and
> years before 1 AD from a year zero, so 0000 is 1 BC and -0001 is
> 2 BC. PostgreSQL accepts neither; write 10000-01-02 and
> 0002-01-02 BC instead.)

Looking at the wiki page again, I see:

To represent years before 0000 or after 9999, the standard also
permits the expansion of the year representation but only by prior
agreement between the sender and the receiver.[25] An expanded
year representation [±YYYYY] must have an agreed-upon number of
extra year digits beyond the four-digit minimum, and it must be
prefixed with a + or - sign[26] instead of the more common AD/BC
(or CE/BCE) notation; by convention 1 BC is labelled +0000,
2 BC is labeled -0001, and so on.[27]

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Kacper Kuras 2026-09-18 16:09:39 Re: 8.5.1. Date/Time Input
Previous Message Kacper Kuras 2026-09-18 14:50:20 Re: 8.5.1. Date/Time Input