On Mon, 3 Feb 2025 at 11:21, Álvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On 2025-Feb-03, Robert Treat wrote: > > > This does seem to come up often enough that it probably is worth being > > a bit more explicit about how this works; attached patch attempts > > that. > > LGTM. > > > Note, I dropped the bit about GMT; that change was made ~40 years ago, > > and I suspect it is close to noise for many people these days, though > > it could be added back if folks feel strongly about it. > > I don't feel strongly about it, but another option might be to add a > <footnote> so that it is still there but less intrusive. Grepping for > GMT in the postgres repo there are still over 1400 matches of all kinds. > > > As Tom notes above, what to store is debatable, and generally seems to > > conflate storage and display desires together, which makes it hard to > > imagine a generic enough implementation to put into core, but there > > are some attempts to solve this problem floating around in extension > > land. See > https://github.com/mweber26/timestampandtz/blob/master/README.md > > as one such attempt. > > Another simple option is to store a timezone name in a separate column, > which you can then use in the AT TIME ZONE clause. This is of course > more wasteful than storing a 2-byte zone identifier as the > timestampandtz extension does. > If anything I'd advocate creating a type which stored both. Storing the TZ in another column would complicate things if the data were to be sent in binary. Is there a case where we would send two attributes for one in binary ? Dave
