On Sat, Aug 14, 2021 at 10:03:01AM +0200, Peter Eisentraut wrote:
> 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.
The way the standard defines time zones, namely as fix offsets from
UTC, is just ludicrous and has been baseless in fact much longer than
SQL has existed. If we're going to capture input time zones, we
should come up with a way to capture the time zone as it existed when
the write occurred, i.e. both its name and the UTC offset it
represented at that time of the write.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
