Potential BUG: ADO Provider for Oracle v9

Greetings all. For lack of knowing a "proper" place to post this, I am posting this message here...

A couple of weeks back, I requested help from this group regarding a daylight savings time issue I was having. I have been working on this since DST began back in April. I have isolated the cause of the problem that we were having as well as the solution.

BACKGROUND Once Daylight Saving Time (DST) began this April, we have been having problems with our Crystal Reports and any other query that used the ADO provider for Oracle: Date/time was displaying one hour earlier then it should have been.

     Our dates are stored in EPOCH/Unix time as Number(15) in our tables. We convert the dates to DATE type in our views. The database is Ora 8i (v8.1.7) running on Solaris 5.6. The Unix server is set to US/Eastern and all date/times on the server match our NT domain.

     Our reports run on a Windows 2000 server from Crystal Enterprise 9. We use a mixture of drivers including Crystal Reports Wireline driver, Oracle ADO, BMC Remedy ODBC, and a couple of others.

PROBLEM Times shown on reports were being displayed one hour earlier than the database time, but only for some reports. The problem could be masked by turning of the Windows Auto DST feature, but the time could not be adjusted to local time because this would change the times on the reports again and caused some of our other reports to become wrong.

SOLUTION The solution that we came up through a lot of testing was to install the Oracle 9.0.1 client on the server (custom, including Windows interfaces). We setup an ODBC DSN using the Oracle driver in Ora92_Home. Our reports now show the correct date and our only issue remains to update our other reports to use this new DSN.

If you come across problems with Daylight Savings or time shifting, other useful suggestions I received including looking at the TZ variable on the Unix servers (OK in my case). I wish I could report this bug to Oracle so they could look into this an confirm it as a bug or determine which conditions it occurs under.

    If anyone else has a similar problem, I'd be interested in hearing from you to share information. I have included my salient environment information in this posting in the hope that others may benefit from my solution.

Best Regards!

David Sanabria

-- 
N. David Sanabria
Specialist, DA
The Hartford, Infrastructure Solutions Department
Online Services Information Delivery
W: 1.860.547.7786 * M: 1.860.916.3489
@: david.sanabria_at_hartfordthe.com
(move THE to before Hartford to send me email)
_Don't be afraid to take a big step if one is indicated; you can't cross 
a chasm in two small jumps._ David Lloyd George