Thread: IDT timezone

IDT timezone

From
"Brandon Metcalf"
Date:
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

Re: IDT timezone

From
Tom Lane
Date:
"Brandon Metcalf" <bmetcalf@nortel.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

Re: IDT timezone

From
"Brandon Metcalf"
Date:
t == tgl@sss.pgh.pa.us writes:

 t> "Brandon Metcalf" <bmetcalf@nortel.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

Re: IDT timezone

From
Andrew - Supernews
Date:
On 2006-04-21, "Brandon Metcalf" <bmetcalf@nortel.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