On 10/10/07, Tom Lane <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org