Robert Treat writes:
> On Thu, Feb 6, 2025 at 5:33 PM Tom Lane wrote:
>> Here's a combined proposal that also adds glossary entries.
> +1
OK, pushed.
regards, tom lane
On Thu, Feb 6, 2025 at 5:33 PM Tom Lane wrote:
> Robert Treat writes:
> > On Mon, Feb 3, 2025 at 12:23 PM Tom Lane wrote:
> >> Hmm, I kind of like the up-front statement that timestamptz stores
> >> UTC. How about this simpler change?
>
> > I thought the re-order made sense since the preceding
Robert Treat writes:
> On Mon, Feb 3, 2025 at 12:23 PM Tom Lane wrote:
>> Hmm, I kind of like the up-front statement that timestamptz stores
>> UTC. How about this simpler change?
> I thought the re-order made sense since the preceding paragraph talks
> exclusively about behavior, so this parag
Thank you. I believe that explanation would have helped.
FWIW, I ultimately decided to simply duplicate the column:
1. keep the timestamp column for sorting/filters/etc.
2. add a full iso 8601 column as text for straightforward client handling
(avoids forcing the client to stitch the data back tog
On Mon, Feb 3, 2025 at 12:23 PM Tom Lane wrote:
>
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > 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.
>
> > L
On Mon, 3 Feb 2025 at 11:21, Álvaro Herrera 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;
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> 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.
Hmm, I kind of like the up-front statement that timestampt
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 n
On Mon, Jan 27, 2025 at 9:36 AM Tom Lane wrote:
>
> Laurenz Albe writes:
> > On Mon, 2025-01-27 at 07:51 +, PG Doc comments form wrote:
> >> Suggestion: Assuming my understanding is accurate - clarify for the reader
> >> that time zone offset is lost (after conversion to UTC). At risk of stat
Laurenz Albe writes:
> On Mon, 2025-01-27 at 07:51 +, PG Doc comments form wrote:
>> Suggestion: Assuming my understanding is accurate - clarify for the reader
>> that time zone offset is lost (after conversion to UTC). At risk of stating
>> the obvious: "timestamp with time zone" is a rather
On Mon, 2025-01-27 at 07:51 +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/datatype-datetime.html
> Description:
>
> Thank you for postgres. I wanted to offer clarification would may help
> othe
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/17/datatype-datetime.html
Description:
Thank you for postgres. I wanted to offer clarification would may help
others in the docs on time stamps (after discovering subtle issues have
significa
12 matches
Mail list logo
