We were running on 6.4 for quite a while and then upgraded directly to
2.6.

In 6.4 ingres we could use the TZ env variable to determine what TZ
offset to apply to date types with time in them when displayed. This
doesn't seem to be the case in 2.6 or 3.x.

I can change II_TIMEZONE_NAME on the fly and it will use that, but it
seems that someone once said "don't do that". Does ingres no longer
use the TZ variable and is it OK to change II_TIMEZONE_NAME on the
fly?

If the answer to those are yes and no, then what is the recommended
method to have date types with time in them apply a TZ offeset for
display based on a given user's configuration? This is primarily
targeted at web based apps where the user can be from a wide variety
of different timezones.

The back end is mostly perl, but this is not a DBI or DBD::Ingres
issue because I can duplicate this issue in a shell script. If I use
one of the various ingres timezone names and either export
II_TIMEZONE_NAME in a shell script it will be used and if I set
$ENV{II_TIMEZONE_NAME} in a perl script it will be used. But, if I
use TZ in either one it won't - it will use II_TIMEZONE_NAME as shown
with ingprenv.

Somewhat offf-post, but is there a reason Ingres doesn't use the
standard timezone names for their timezone names? For example,
America/New_York instead of NA-EASTERN?

Thanks

Dennis

On Jul 9, 10:50 am, droesler <droes...@comcast.net> wrote:
> We were running on 6.4 for quite a while and then upgraded directly to
> 2.6.
>
> In 6.4 ingres we could use the TZ env variable to determine what TZ
> offset to apply to date types with time in them when displayed. This
> doesn't seem to be the case in 2.6 or 3.x.
>
> I can change II_TIMEZONE_NAME on the fly and it will use that, but it
> seems that someone once said "don't do that". Does ingres no longer
> use the TZ variable and is it OK to change II_TIMEZONE_NAME on the
> fly?
>
> If the answer to those are yes and no, then what is the recommended
> method to have date types with time in them apply a TZ offeset for
> display based on a given user's configuration? This is primarily
> targeted at web based apps where the user can be from a wide variety
> of different timezones.
>
> The back end is mostly perl, but this is not a DBI or DBD::Ingres
> issue because I can duplicate this issue in a shell script. If I use
> one of the various ingres timezone names and either export
> II_TIMEZONE_NAME in a shell script it will be used and if I set
> $ENV{II_TIMEZONE_NAME} in a perl script it will be used. But, if I
> use TZ in either one it won't - it will use II_TIMEZONE_NAME as shown
> with ingprenv.
>
> Somewhat offf-post, but is there a reason Ingres doesn't use the
> standard timezone names for their timezone names? For example,
> America/New_York instead of NA-EASTERN?
>
> Thanks
>
> Dennis

Not too sure about the TZ variable, but 2.6 stores dates with times as
GMT and converts them to the local time zone at the time of
selection. 6.4 didn't do this. Not sure about the standard timezone
names - didn't know there was an international system for it. e.g.
AEST can mean australian eastern standard time or american eastern
standard time as far as I know.

HTH.

On Jul 9, 1:18 am, sim...@unwired.com.au wrote:
> On Jul 9, 10:50 am, droesler <droes...@comcast.net> wrote:
>
>
>
> > We were running on 6.4 for quite a while and then upgraded directly to
> > 2.6.
>
> > In 6.4 ingres we could use the TZ env variable to determine what TZ
> > offset to apply to date types with time in them when displayed. This
> > doesn't seem to be the case in 2.6 or 3.x.
>
> > I can change II_TIMEZONE_NAME on the fly and it will use that, but it
> > seems that someone once said "don't do that". Does ingres no longer
> > use the TZ variable and is it OK to change II_TIMEZONE_NAME on the
> > fly?
>
> > If the answer to those are yes and no, then what is the recommended
> > method to have date types with time in them apply a TZ offeset for
> > display based on a given user's configuration? This is primarily
> > targeted at web based apps where the user can be from a wide variety
> > of different timezones.
>
> > The back end is mostly perl, but this is not a DBI or DBD::Ingres
> > issue because I can duplicate this issue in a shell script. If I use
> > one of the various ingres timezone names and either export
> > II_TIMEZONE_NAME in a shell script it will be used and if I set
> > $ENV{II_TIMEZONE_NAME} in a perl script it will be used. But, if I
> > use TZ in either one it won't - it will use II_TIMEZONE_NAME as shown
> > with ingprenv.
>
> > Somewhat offf-post, but is there a reason Ingres doesn't use the
> > standard timezone names for their timezone names? For example,
> > America/New_York instead of NA-EASTERN?

>
> Not too sure about the TZ variable, but 2.6 stores dates with times as
> GMT
Actually I believe its GMT relative to seconds since the "epoch" which
ingres has done for as long as I can remember
> and converts them to the local time zone at the time of

This is the issue - what does ingres think "local timezone" is? As
far as I can tell it thinks what ever is in II_TIMEZONE_NAME, which I
don't believe was always the case if TZ was available in the
environment.

> selection. 6.4 didn't do this. Not sure about the standard timezone
> names - didn't know there was an international system for it. e.g.
> AEST can mean australian eastern standard time or american eastern

That would be EST or EST5DST for the eastern US.

Cheers

Dennis

<simonl@unwired.com.au> wrote in message
news:1183958311.442332.20050@a26g2000pre.googlegro ups.com...
> On Jul 9, 10:50 am, droesler <droes...@comcast.net> wrote:

snip

>2.6 stores dates with times as
> GMT and converts them to the local time zone at the time of
> selection. 6.4 didn't do this.

snip

I don't think that statement is true. AFAIK ingres has always stored dates
as GMT at translated them as required to the clients timezone.

Paul

Hello All,



I have installed ingres2006-9.1.0-123-com-win-x86-DotNet, with VS 2005.

I can select Ingres in the server explorer, see tables etc, but I'm unable to see the Ingres .Net data provider as an option when I try to define a shared data source.



Is this version of the Ingres .Net data provider capable of this, or is it a configuration option.



Thanks.

At 12:50 AM +0000 7/9/07, droesler wrote:
>In 6.4 ingres we could use the TZ env variable to determine what TZ
>offset to apply to date types with time in them when displayed. This
>doesn't seem to be the case in 2.6 or 3.x.
>
>I can change II_TIMEZONE_NAME on the fly and it will use that, but it
>seems that someone once said "don't do that". Does ingres no longer
>use the TZ variable and is it OK to change II_TIMEZONE_NAME on the
>fly?

Ingres does not use TZ, and it should be OK to change II_TIMEZONE_NAME
"on the fly" (meaning at session connect) as long as you understand
the implications. II_TIMEZONE_NAME is used for all interpretations
of date+time, both input and output. Date/times going into a
table are converted to GMT according to the timezone in effect
for that session.

>
>Somewhat offf-post, but is there a reason Ingres doesn't use the
>standard timezone names for their timezone names? For example,
>America/New_York instead of NA-EASTERN?

Are there in fact standard timezone names? Part of the reason for
the entire II_TIMEZONE_NAME business is that there wasn't any
reliably portable library level timezone support, at least not in
the mid-90's when the code was done. Naming was the least of
their problems. Even now I'm not aware of a world standard
for timezone names. (not that I have looked very hard...)

Karl

On Jul 9, 6:00 pm, Karl & Betty Schendel <schen...@kbcomputer.com>
wrote:
> At 12:50 AM +0000 7/9/07, droesler wrote:
>
> >In 6.4 ingres we could use the TZ env variable to determine what TZ
> >offset to apply to date types with time in them when displayed. This
> >doesn't seem to be the case in 2.6 or 3.x.
>
> >I can change II_TIMEZONE_NAME on the fly and it will use that, but it
> >seems that someone once said "don't do that". Does ingres no longer
> >use the TZ variable and is it OK to change II_TIMEZONE_NAME on the
> >fly?

> Ingres does not use TZ, and it should be OK to change II_TIMEZONE_NAME
> "on the fly" (meaning at session connect) as long as you understand
> the implications.
Thanks. I can't remember who said "don't do that".

> >Somewhat offf-post, but is there a reason Ingres doesn't use the
> >standard timezone names for their timezone names? For example,
> >America/New_York instead of NA-EASTERN?
>
> Are there in fact standard timezone names?

Maybe standard wasn't the term to use. I was referring to the
zoneinfo database.
Possibly GMT[+|-]nn may be the most reliable method across systems,
but that doesn't seem to suggest DST if it is applicable.

> Part of the reason for
> the entire II_TIMEZONE_NAME business is that there wasn't any
> reliably portable library level timezone support, at least not in
> the mid-90's when the code was done. Naming was the least of
> their problems. Even now I'm not aware of a world standard
> for timezone names. (not that I have looked very hard...)

Not that wikipedia is always the definitive answer :-), but there is
this
http://en.wikipedia.org/wiki/Zoneinfo

As always, appreciate your input Karl.

Dennis