Re: Timezones (in 8.5?)

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Kevin(dot)Grittner(at)wicourts(dot)gov ("Kevin Grittner"), "hernan gonzalez" <hgonzalez(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Timezones (in 8.5?)
Date: 2009-11-19 04:18:19
Message-ID: 87my2jcgvi.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Kevin" == "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:

>> If he meant (A), then you store the event as:
>> (ts,tz) = (timestamp '2010-07-27 10:30:00',
>> 'Chile/Santiago')

>> If he meant (B), then you store the event as
>> (tsz,tz) = (timestamp '2010-07-27 10:30:00' at time zone
>> 'Chile/Santiago', 'Chile/Santiago')

Kevin> You seem to be agreeing that these problems can't be solved
Kevin> without storing a time zone string in addition to the
Kevin> timestamp. As I read it, Hernán was wishing for types which
Kevin> include this, rather than having to do the above dance with
Kevin> multiple values.

Right, but including more data in a single type is the wrong approach,
since it complicates the semantics and interferes with normalization.
For example, if you have a type T which incorporates a timestamp and a
timezone, what semantics does the T = T operator have? What semantics
apply if the definitions of timezones change? What if you're storing
times of events at specific places; in that case you want to associate
the timezone with the _place_ not the event (so that if the timezone
rules change, moving the place from one timezone to another, you only
have to change the place, not all the events that refer to it).

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sushant Sinha 2009-11-19 04:29:12 Re: Very bad FTS performance with the Polish config
Previous Message Tom Lane 2009-11-19 04:12:33 Re: Listen / Notify - what to do when the queue is full