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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
