Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> The timestamp and the timezone in which that timestamp was
>>> entered are two separate pieces of data and *ought* to be in two
>>> separate fields.
>
>> So, if you're grabbing a timestamp and the time zone for it, how
>> do you ensure you've done that atomically if you're at the
>> boundary of a DST change?
>
> In my view of the world, the timezone that you are in is not an
> object that changes across a DST boundary.
You're right -- the moment in time should be fixed like in the
current PostgreSQL "timestamp with time zone", and the time zone
doesn't change with DST. Not an intentional read herring, but
definitely some muddy thinking there.
That weakens the argument for such a data type. Even with that, I
suspect that its value as a convenience for application programmers
would be sufficient that an extension to provide such functionality
would get used. Essentially the current timestamptz bundled with a
time zone and which is, by default, displayed "at time zone" of the
attached time zone on output.
-Kevin