Re: timestamp with time zone a la sql99

From: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: timestamp with time zone a la sql99
Date: 2004-10-22 14:28:12
Message-ID: Pine.LNX.4.44.0410221615150.2015-100000@zigo.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 22 Oct 2004, Tom Lane wrote:

> As far as I can tell, Dennis is planning slavish adherence to the spec,
> which will mean that the datatype is unable to cope effectively with
> daylight-savings issues. So I'm unconvinced that it will be very
> helpful to you for remembering local time in addition to true
> (universal) time.

And exactly what issues is it that you see? The only thing I can think of
is if you have a timestamp and then add an interval to it so we jump past
the daylight saving time change date. Then the new timestamp will keep the
old timezone data of say +01 even though we now have jumped into the
daylight saving period of +02.

If you are just storing actual timestamps then the standard definition
works just fine. If I store '2004-10-22 16:20:04 +02' then that's exactly
what I get back. No problem what so ever. There is no DST problem with
that.

It's possible that I will introduce some daylight saving bit or something
like that, I'm not sure yet and I will not commit to anything until I've
thought it over. I don't think there are that much of a problem as you
claim however. Could you give a concret example where it will be a
problem?

My current thinking is that storing the time zone value as HH:MM is
just fine and you avoid all the problems with political changes of when
the DST is in effect or not.

--
/Dennis Björklund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Bjorklund 2004-10-22 14:40:33 Re: SET SESSION SESSION AUTHORIZATION
Previous Message Tom Lane 2004-10-22 14:21:50 Re: SET SESSION SESSION AUTHORIZATION