Re: Timezone database changes

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. +