Lists: | pgsql-general |
---|
From: | "Brandon Metcalf" <bmetcalf(at)nortel(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | IDT timezone |
Date: | 2006-04-21 15:40:47 |
Message-ID: | Pine.LNX.4.58L.0604211036190.10958@cash.rhiamet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
What is the best way to handle timestamps with a timezone of IDT? I
see that I could modify src/backend/utils/adt/datetime.c to support
IDT, but what is the best solution?
Basically, I have an application where I'm grabbing the timezone from
the output of date(1) and appending that to a timestamp before I do an
INSERT. In the situations where the timezone is IDT, the INSERT
fails.
--
Brandon
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Brandon Metcalf" <bmetcalf(at)nortel(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: IDT timezone |
Date: | 2006-04-21 17:46:13 |
Message-ID: | 12369.1145641573@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
"Brandon Metcalf" <bmetcalf(at)nortel(dot)com> writes:
> What is the best way to handle timestamps with a timezone of IDT? I
> see that I could modify src/backend/utils/adt/datetime.c to support
> IDT, but what is the best solution?
Right at the moment, that's the only solution. We've wanted for awhile
to push the timezone abbreviations out to a configuration file so that
people could muck with them without rebuilding the server ... but it's
never gotten to the top of anyone's to-do list.
regards, tom lane
From: | "Brandon Metcalf" <bmetcalf(at)nortel(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: IDT timezone |
Date: | 2006-04-21 17:51:55 |
Message-ID: | Pine.LNX.4.58L.0604211251440.10958@cash.rhiamet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
t == tgl(at)sss(dot)pgh(dot)pa(dot)us writes:
t> "Brandon Metcalf" <bmetcalf(at)nortel(dot)com> writes:
t> > What is the best way to handle timestamps with a timezone of IDT? I
t> > see that I could modify src/backend/utils/adt/datetime.c to support
t> > IDT, but what is the best solution?
t> Right at the moment, that's the only solution. We've wanted for awhile
t> to push the timezone abbreviations out to a configuration file so that
t> people could muck with them without rebuilding the server ... but it's
t> never gotten to the top of anyone's to-do list.
OK. Thanks.
--
Brandon
From: | Andrew - Supernews <andrew+nonews(at)supernews(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: IDT timezone |
Date: | 2006-04-22 09:06:38 |
Message-ID: | slrne4jsgu.tl6.andrew+nonews@trinity.supernews.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
On 2006-04-21, "Brandon Metcalf" <bmetcalf(at)nortel(dot)com> wrote:
> What is the best way to handle timestamps with a timezone of IDT? I
> see that I could modify src/backend/utils/adt/datetime.c to support
> IDT, but what is the best solution?
>
> Basically, I have an application where I'm grabbing the timezone from
> the output of date(1) and appending that to a timestamp before I do an
> INSERT. In the situations where the timezone is IDT, the INSERT
> fails.
On reasonably up-to-date systems, why not use the %z format specifier for
date(1) to get a numeric zone offset?
Better yet, omit the offset entirely and make sure that the session timezone
is correctly set (to, presumably, 'Asia/Jerusalem') and let postgres figure
out whether DST is in effect (which it can do just as well as date(1) can,
provided you're keeping reasonably up to date - pg 8.0 onwards carry their
own copy of the standard zoneinfo database with them).
Zone names like 'IST' are in any event entirely ambiguous and should never
be used - you could regard it as a pure fluke that pg happens to resolve
'IST' as +0200 rather than +0530...
--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services