Tom Lane wrote: > Exactly ... there is more than one right answer here. The answer that > PG's TIMESTAMP WITH TIME ZONE code deems to be right is that UTC is > reality. That's a definition that is indeed useful for a wide variety > of real-world problems. In a lot of cases where it's not so useful, > TIMESTAMP WITHOUT TIME ZONE does the right thing. I'm not sure that > there's a significant use-case for a third behavior, and I definitely > don't think you can make an argument from first principles that the > UTC-based definition is wrong. > > (FWIW, Red Hat has been struggling with this exact problem of > cross-time-zone meeting times for some years now, and has pretty much > arrived at the conclusion that company meeting times are to be defined > in UTC...) > > 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.
I am thinking additional documention is the only good solution here. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
