Re: Support for DATETIMEOFFSET

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jeremy Morton <admin(at)game-point(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeremy Morton <postgres(at)game-point(dot)net>, Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support for DATETIMEOFFSET
Date: 2020-04-17 23:25:11
Message-ID: 20200417232511.GA15836@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Apr-17, Jeremy Morton wrote:

> How could the ORM use timestamptz when that doesn't actually store both a
> datetime and an offset?

There are lots of ways in which timestamptz can be used. The most
typical one is to rely on the TimeZone configuration parameter; another
very typical one is to have a zone specification at the end of the
timestamp literal such as "+03" or "Europe/Madrid", as Andreas Karlsson
already mentioned. In addition to those, the "AT TIME ZONE" operator
can be used with a bare timestamp.

The main point of the timestamptz type is that both the input and output
are timezone-aware. This timezone is not *stored*, but in most cases it
doesn't need to be. I have never seen a case where an application
needed a timezone to be *stored* together with each timestamp value.
It's just not useful.

If you want to set up an output timezone, you can set it for each
specific user (for example). Then all timestamps you show to that user
will use that timezone. It's a very easy and convenient thing.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2020-04-17 23:40:25 Re: Poll: are people okay with function/operator table redesign?
Previous Message Tom Lane 2020-04-17 23:16:59 Re: Poll: are people okay with function/operator table redesign?