RE: TZ info used by dB drivers
- From: d_roesler@xxxxxxxxxxx (D Roesler)
- Date: Mon, 9 Jul 2007 09:06:04 -0600
On 7/8/07, d_roesler@xxxxxxxxxxx <d_roesler@xxxxxxxxxxx> wrote:
I'm trying to track down how TZ info is used by a dB driver, in this case >> DBD::Ingres.
It would appear that TZ is getting passed to the driver on the first
connection (when the driver is installed) and doesn't see changes to
$ENV{TZ} between the first connection and subsequent connections in the >> running script.
If this is a driver issue is there an "uninstall driver" method, such
that subsequent connections will reload the driver in the running script >> so the changed $ENV{TZ} will be seen? If this is a DBI issue is there a >> way for the changed $ENV{TZ} value to be seen in the driver?
On 7/9/07,Jonathan Leffler [mailto:jonathan.leffler@xxxxxxxxx] wrote:
There are multiple places that could be affected by this - I just spent
the weekend chasing timezones around a JDBC driver, and it is painful.
The underlying Unix API really only provides one function call to control > the current time zone, and call is tzset(). No arguments, no return
value. It gets called implicitly by a bunch of functions, too, if they
think it necessary. The result is 'gating'; the time zone is set once and > not adjustable thereafter -- which is what you are observing.
Speculation: maybe, just maybe, if you set the environment and manage to
explicitly call tzset() afterwards, it might, conceivable notice the new
time zone. But I'm not confident that it would, and could easily be
platform specific.
It seems this is getting cached somewhere and I'm guessing the Ingres driver. Maybe this behavior is specific to Ingres? Given this seems to be cached I'm not sure if tzset() would have any effect, but an interesting idea :-)
If I set $ENV{TZ} and call localtime I get what I expect, and if I change $ENV{TZ} and call localtime again I get what I expect - so it would appear to be DBI/DBD::Ingres related.
Given the above assumptions, is there a way to destroy the driver handle so that the next call to connect() would force the driver to be loaded again, which I presume would then see the new value of $ENV{TZ}? I realize this has some dangers if you're not keeping track of any open transactions.
The bummer is, given that you can have simultaneous connections to different databases, it would be nice if each connection could set its timezone. I tried using a private variable in the connection string attributes to see if that would change anything and it didn't.
Dennis
.
- Follow-Ups:
- Re: TZ info used by dB drivers
- From: Henrik Tougaard
- Re: TZ info used by dB drivers
- From: Henrik Tougaard
- Re: TZ info used by dB drivers
- References:
- Re: TZ info used by dB drivers
- From: Jonathan Leffler
- Re: TZ info used by dB drivers
- Prev by Date: Re: TZ info used by dB drivers
- Next by Date: Re: Oracle make test failing on HP/UX
- Previous by thread: Re: TZ info used by dB drivers
- Next by thread: Re: TZ info used by dB drivers
- Index(es):
Relevant Pages
|
