Re: Problem with DBTIMEZONE
Date: Thu, 16 Oct 2008 15:33:25 -0500
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;
"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.
> 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
>> Bradd Piontek
>> "Next to doing a good job yourself,
>> the greatest joy is in having someone
>> else do a first-class job under your
>> -- William Feather