The ResultSet's getDate method from AbstractResultSet
class should normalize the hours, minutes, seconds
and milliseconds for the date value catched from the
database.
Look at this example:
The two examples had been extracted of the same
column and register of a table.
The original value of the register is:
2003-02-28 :13:55:00.0
1 - Using getDate(1) and java.sql.Date:
toString() brings up: 2003-02-28
getTime() brings up: 1046401200000
2 - Using getTimestamp(1) and java.sql.Timestamp:
toString() brings up: 2003-02-28 13:55:00.0
getTime() brings up: 1046451300000
The long values from getTime method had been equal,
something that would not have to happen, since the
specification says that the values(hours, minutes,
seconds and milliseconds) must be normalized the zero.
I made the same test with Oracle and Oracle Thin Driver
and the long values were differents.
I have seen the source code for a while and at getDate
method in AbstractResultSet class I saw the following
stretch of code:
public java.sql.Date getDate(int index) throws
SQLException {
java.sql.Date result = null;
java.sql.Timestamp tmp = getTimestamp(index);
if( tmp != null ) result = new java.sql.Date(tmp.getTime()); return result; }
Logged In: YES
user_id=722437
Sorry, I copied thoses lines from Oracle output. Here is the
output when using jTDS Driver with SQL Server 7
1 - Using getDate(1) and java.sql.Date:
toString() brings up: 2003-02-28
getTime() brings up: 1046451300000
2 - Using getTimestamp(1) and java.sql.Timestamp:
toString() brings up: 2003-02-28 13:55:00.0
getTime() brings up: 1046451300000
Logged In: YES
user_id=722437
Looks like the same problem occurs when using getTime()
method. The YEAR, MONTH and DAY_OF_MONTH from the
value of column should be normalized to 1970 1 January.
Logged In: YES
user_id=564978
Bruno,
Thanks for your detailed description of the issues. I'll try to fix
them as soon as I find some time to do it.
Regards,
Alin.
Logged In: YES
user_id=722437
alin, I made a fix myself to the source, so I can use the driver
in my project. :) If there is any open slot in jTDS project so I
can go into it? :)
thankz for answering :D
Logged In: YES
user_id=564978
Bruno,
Anyone is welcome to join jTDS. Most of the project
members remained there for years, they don't work on the
project anymore. In fact, during the last year I have been the
only active member. There have been other people that
helped me at one point or another, but most of them aren't
even members. During the last few months, even I haven't
managed to get too much work done, so it would really help
having some new around. :o)
So, if you would like to join jTDS, tell me and I'll add you to
the developers list. Otherwise, you can post your patch,
either here or in the Patches section.
Regards,
Alin.
Logged In: YES
user_id=722437
Sure! Of course I want to join the project! I have no much
free time too, because the university and my real job, but,
hey! I always go to bed after 2 AM! :)
So, if you're interest with my help too, let me know. :)
PS: sorry about my english. I just are good enough to read
documents, articles and hi-tech stuffs/news... ;)
Logged In: YES
user_id=564978
Ok then, you're a member! :o) Enjoy... And let me know if
you encounter any problems.
Alin.
Logged In: NO
I create a table with a timestamp column.
When I try to retrieve the value (using resultset.getTimestamp
(1)), an error is thrown saying that the value is not a
Timestamp type but a [B type (Byte Array)
Logged In: YES
user_id=564978
The MSSQL TIMESTAMP type is by no means the same
thing as the Java Timestamp. In MSSQL TIMESTAMP is a
binary value generated from the current date and time and the
MAC address of the computer, while in Java it's a structure
for managing time values (between 0:00:00.0 and
23:59:59.999...).
If you want to use the Java Timestamp you'll have to create a
DATETIME column in MSSQL.
And by the way, could you create an account on
SourceForge for yourself? It would be easier both for you and
for others to track changes to the issues you bring up.
Alin.
Logged In: YES
user_id=564978
Ok, I finally fixed the issue. It took me a while to figure out
why the fix was seemingly providing wrong results (they were
actually correct) but it seems to be working fine.
I cannot commit the changes from this machine, I will do it as
soon as possible, though.
Alin.
Logged In: YES
user_id=564978
Now it's in the repository. It will also be in the next release.
Alin.