Re: Storing time values via jdbc thin driver

From: gym dot scuba dot kennedy at gmail <kennedyii_at_verizon.net>
Date: Fri, 28 Nov 2008 22:54:55 GMT
Message-ID: <3F_Xk.1650$QX3.341@nwrddc02.gnilink.net>

"Chris Seidel" <cseidel_at_arcor.de> wrote in message news:49304bf2$0$31876$9b4e6d93_at_newsspool3.arcor-online.net...
> gym dot scuba dot kennedy at gmail wrote:
>
>> I am not sure I understand the question. Wouldn't you be specifying
>> the date and the time? In Oracle you don't have just time anyway. You
>> have a date and a time. You could have a string field that
>> represents a time. (ugh) or you could use some sort of integer to
>> represent the time. It looks like you have an impediance mismatch
>> between Java and Oracle.
>
> Yes. Java knows Time and Date, Oracle only Date.
> Java says that for time the date part must be set to 1970-01-01.
> But it seems the 9.2 driver sets it to 1900-01-01.
> Now all my queries are broken with a 10.2 driver.
>

Actually no. Oracle only knows time and date together. In Oracle there is no stand alone time data type. There is a date data type which has a time component. (to seconds) There is also a timestamp data type which has date and time where the time can be parts of a second. (accuracy depends on OS, optionally you can have a timestamp with a timezone component also) What I have seen is some programers will request a data type from Oracle as a string or character value. This causes all sorts of problems. (see nls date format setting for a session) I encourage you to use native types and not to have dates or times as strings. This is the impediance mismatch I alluded to.

I suspect Sybrand is correct. If you go into SQLPlus and do a select on the column in question what do you get? You will get a string representation of the date field. (which is not a date, it is a string formatted as a date a very different thing just like 2 and "2" are different things in Java.)

eg
select mydatefield from mytable;
or
select to_char(mydatefield,'mm/dd/yyyy') from mytable; or
select to_char(mydatefield,'mm/dd/yyyy hh24:mi:ss') from mytable; or
select to_char(mydatefield,'mm/dd/yyyy hh:mi:ss AM') from mytable; etc.

At the programming level you will deal with dates (hopefully) as native types, not a string representation of the type.

Jim Received on Fri Nov 28 2008 - 16:54:55 CST

Original text of this message