Обсуждение: IDT timezone
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
"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
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
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