[EMAIL PROTECTED] wrote:
>>> On 7/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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...
