From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgmis@posteo.net
cc: pgsql-general@postgresql.org
Subject: Re: RFC 9557 / IXDTF
In-reply-to: <145c7185c29456e42a9325fe1df63222@posteo.net>
References: <145c7185c29456e42a9325fe1df63222@posteo.net>
Comments: In-reply-to pgmis@posteo.net
	message dated "Sun, 16 Nov 2025 19:43:47 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <403585.1763330218.1@sss.pgh.pa.us>
Date: Sun, 16 Nov 2025 16:56:58 -0500
Message-ID: <403586.1763330218@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/403586.1763330218%40sss.pgh.pa.us>
Precedence: bulk

pgmis@posteo.net writes:
> does postgres consider some sort of implementation of rfc9557 IXDTF?
> This is new time internet time format which extends timestamps with 
> timezone info together with the offset
> - https://datatracker.ietf.org/doc/html/rfc9557
> - https://en.wikipedia.org/wiki/RFC_9557#Usage

It's not on the radar at the moment.  If this standard gets any
real uptake (too soon to tell), somebody might build an extension
datatype that works with it.

AFAICT from a quick read of 9557, the intent is precisely to represent
*more* information than just a point in time, or even just a point in
time and an intended timezone.  So IMO it wouldn't make any sense for
the built-in timestamptz type to deal with this.  Yeah we could make
timestamptz_in read this format, but it'd be throwing away all of the
additional information over an RFC 3339 timestamp, which seems like
not the right thing.

			regards, tom lane