Re: Problem with DBTIMEZONE

WOuldn't the numerical offsetfor Mountain time be -06:00 ? I believe they could quickly modify their code to use TZ_OFFSET

SQL> select TZ_OFFSET(DBTIMEZONE) from dual;

TZ_OFFS

Bradd Piontek
  "Next to doing a good job yourself,

        the greatest joy is in having someone
        else do a first-class job under your
        direction."

• William Feather

On Thu, Oct 16, 2008 at 3:30 PM, Sandra Becker <sbecker6925_at_gmail.com>wrote:

> No idea what it was set to on the old database and they repurposed that
> server about 6 weeks ago, so no way to go back and check. Changing the time
> zone does not get rid of the error. The problem is that the way this
> function is written, anything other than numerical values in the time zone
> throws errors.
>
> We're going to set the time zone to +06:00, bounce the database and see if
> the reports start working again. We understand that as soon as daylight
> saving time ends on November 2nd, we're off by an hour again and will have
> to do this exercise again if we haven't fixed our code by then.
>
> Sandy
>
> On Thu, Oct 16, 2008 at 2:23 PM, Bradd Piontek <piontekdd_at_gmail.com>wrote:
>
>> Would it make sense to change the time zone to 'US/Mountain' ? this should
>> take DST into consideration.
>> What was it set to on the old database? Was the old database a 9i
>> database?
>>
>> Bradd Piontek
>> "Next to doing a good job yourself,
>> the greatest joy is in having someone
>> else do a first-class job under your
>> direction."
>> -- William Feather
>>
>

--
http://www.freelists.org/webpage/oracle-l