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
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? |