On 13.08.21 19:07, Tom Lane wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> On Fri, Aug 13, 2021 at 9:28 AM Simon Riggs <simon.riggs@enterprisedb.com>
>> wrote:
>>> The only hope is to eventually change the default, so probably
>>> the best thing is to apply pressure via the SQL Std process.
>
>> Then there is no hope because this makes the situation worse.
>
> Agreed; the points I made upthread are just as valid if the change
> is made in the standard. But I'd be astonished if the SQL committee
> would consider such a change anyway.
AFAIU, our timestamp with time zone type doesn't really do what the SQL
standard specifies anyway, as it doesn't actually record the time zone,
but it's more of a "timestamp with time zone aware formatting". For
SQL, it might make sense to add a (third) time stamp type that behaves
more like that.