TZ info used by dB drivers

Hi,

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?

Thanks

Dennis

Re: TZ info used by dB drivers

------=_Part_1474_22881523.1183988255228
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/8/07, d_roesler@agilent.com 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?
>


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.

The java.util.Date, java.util.Calendar and java.util.TimeZone APIs allow for
a lot of control and information for which there is no corresponding C API,
sadly.


--
Jonathan Leffler #include
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

------=_Part_1474_22881523.1183988255228--

RE: TZ info used by dB drivers

>> On 7/8/07, d_roesler@agilent.com wrote:=20
>> I'm trying to track down how TZ info is used by a dB driver, in this =
case >> DBD::Ingres.=20

>> It would appear that TZ is getting passed to the driver on the first=20
>> connection (when the driver is installed) and doesn't see changes to=20
>> $ENV{TZ} between the first connection and subsequent connections in =
the >> running script.=20

>> 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?=20

> On 7/9/07,Jonathan Leffler [mailto:jonathan.leffler@gmail.com] wrote:
> There are multiple places that could be affected by this - I just =
spent=20
> 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().=A0 No arguments, =
no return=20
> value.=A0 It gets called implicitly by a bunch of functions, too, if =
they=20
> think it necessary.=A0 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=20
> explicitly call tzset() afterwards, it might, conceivable notice the =
new=20
> time zone.=A0 But I'm not confident that it would, and could easily be =

> platform specific.=20

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

Re: TZ info used by dB drivers

d_roesler@agilent.com wrote:
>>> On 7/8/07, d_roesler@agilent.com 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.
>>>
>
>
> 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.
>
>
The DBD::Ingres driver does not use the TZ env.variable in any way. None
what so ever!

Ingres does'nt use the TZ env.var. either - it uses II_TIMEZONE and the
value of that is not changed or manipulated in any way by DBD::Ingres.

So there is no reason to unload the driver - unless TimB has cached
II_TIMEZONE somewhere in the non-private parts of the driver data (which
I doubt very much).

DBD::Ingres does exactly the same as you could do yourself in Embedded
SQL - using dynamic SQL.

Timezones are a pain. And I wish you the best of luck with you quest...


--
Henrik Tougaard, DBD::Ingres maintainer
Adapt A/S, Copenhagen, Denmark

Re: TZ info used by dB drivers

d_roesler@agilent.com wrote:
>>> On 7/8/07, d_roesler@agilent.com 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.
>
> 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.
>
>
The DBD::Ingres driver does not use the TZ env.variable in any way. None
what so ever!

Ingres does'nt use the TZ env.var. either - it uses II_TIMEZONE and the
value of that is not changed or manipulated in any way by DBD::Ingres.

So there is no reason to unload the driver - unless TimB has cached
II_TIMEZONE somewhere in the non-private parts of the driver data (which
I doubt very much).

DBD::Ingres does exactly the same as you could do yourself in Embedded
SQL - using dynamic SQL.

Timezones are a pain. And I wish you the best of luck with you quest...