| 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.
| 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 |