From: Tom Lane <tgl@sss.pgh.pa.us>
To: Erik Wienhold <ewie@ewie.name>
cc: Peter Eisentraut <peter@eisentraut.org>,
        Roman =?utf-8?Q?Fro=C5=82ow?= <rofrol@gmail.com>,
        pgsql-docs@lists.postgresql.org
Subject: Re: T is a mandatory date time separator in RFC3339 but documentation
 states differently
In-reply-to: <mmvqgl2yf76ufsb2zug7hjqmu5cqxk4wfy6lkax7beeeeqgn56@svb7qhcyno6t>
References: <fojeaxd2hqux2abmft22nnsll435q2qfmecjlsig2g2th5u2bw@cr3m7rzgaop3>
 <CAFZ1f-9rnK6uZwsUUKDwCkNB9h9zP70oaSfduu+TxrQAxEmwjQ@mail.gmail.com>
 <CAFZ1f-9D3iCcGF8+mLgRffUp6i7m-2mh1GJ5UZbfcZiyjaXQzQ@mail.gmail.com>
 <piavtdd7mhmkpzpgvxaek3hz3e2kan3c2fitn5iqta6nyrpgyl@txongxshxkxw>
 <7njdkzeco47heg6tglzsm5wmmbb56vd66f7pta6gazb2k52viu@av3wruqnylpp>
 <2037453.1699892596@sss.pgh.pa.us>
 <d65bzp5h6j2lroyt3y4t7vlth76hdegjuh67dlsmxqzmzjbvtp@fdc4xs5awb3f>
 <408aa3cd-0085-41c3-855c-3d51a1bc55d3@eisentraut.org>
 <n5j5tsqbh55orr36bhpibcd7k3ckztsu75q4uhmmncbpedu4ok@vib6inzin3el>
 <78c14be8-47f2-4624-9d98-3730b492977e@eisentraut.org>
 <mmvqgl2yf76ufsb2zug7hjqmu5cqxk4wfy6lkax7beeeeqgn56@svb7qhcyno6t>
Comments: In-reply-to Erik Wienhold <ewie@ewie.name>
	message dated "Wed, 15 Nov 2023 13:47:45 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2657880.1700059603.1@sss.pgh.pa.us>
Date: Wed, 15 Nov 2023 09:46:43 -0500
Message-ID: <2657881.1700059603@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2657881.1700059603%40sss.pgh.pa.us>
Precedence: bulk

Erik Wienhold <ewie@ewie.name> writes:
> On 2023-11-15 12:53 +0100, Peter Eisentraut wrote:
>> I think we should reframe "ISO" to mean "ISO 9075" and remove all claims of
>> alignment with ISO 8601 and RFC 3339.

> Agree.  So just list the example inputs without any reference to a
> particular standard, except for ISO 9075 to show that Postgres is
> SQL-standard-compliant?

I think that would remove useful context without actually improving
anything.  (The datetime input code would be far simpler if it
meant only to read the exact format mentioned in the SQL spec.)

			regards, tom lane