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