On 10/10/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The arguments that have been made for storing a zone along with the UTC
> value seem to mostly boil down to "it should present the value the same
> way I entered it", but if you accept that argument then why do we have
> DateStyle? If it's OK to regurgitate "11-12-2007" as "2007-12-11",
> I'm not clear on why adjusting timezone isn't OK.
Actually, what I meant at least (not sure if others meant it), is
storing the value in the timezone it was entered, along with what zone
that was. That makes the value stable with respect to the zone it
belongs to, instead of being stable with respect to UTC. When DST
rules change, the value is in effect "reinterpreted" as if it were
input using the new rules. To me that's also what the name of the
type suggests it does.
I imagine internally it would convert each value to UTC just before
performing any calculations on it, and generally be irritating to work
with. But the public interface would do the "other" right thing.
Well, for political time zones anyway. I have no idea what that
approach is supposed to do with numeric offsets, or the old "PST8PDT"
type stuff.
Anyway, getting back to documentation, I think it's just necessary to
somehow point out the difference between these two behaviors in the
section about the date and time types, and which type is more
appropriate for which situation. I don't know if there's enough room
to provide effective examples without getting too bogged down in
details though.