• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate loses precision when persisting util.Date as timestamp

 
Manzar Zaidi
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I find it happening randomly and much more often than not.
I have a simple Hibernate mapped object that has a util.Date as one of the properties.
I set this Date whenever I create the object and then just persist it using Hibernate.
The target property in the SQL Server 2000 DB is of type datetime. After the inserts, I can compare the inserted values from my logs to find that hibernate in general add 2 millisecond to every date it inserts!!
I do not find any related posting on the net so far.

The piece of relevant code is :



With this code, some values I could observe where like this :

  • utilTime =1163605588780 persistedTime=1163605588780
  • utilTime =1163605624045 persistedTime=1163605624047
  • utilTime =1163605651029 persistedTime=1163605651030
  • utilTime =1163605675544 persistedTime=1163605675543
  • utilTime =1163605703216 persistedTime=1163605703217
  • utilTime =1163605731418 persistedTime=1163605731417




  • I find the bartenders around here are quite seasoned to point out anything I might be doing wrong, before I finally signup for Hibernate forums and post this as bug there.
    Thanks for giving it a look and hopefully thought too.
     
    Paul Sturrock
    Bartender
    Posts: 10336
    Eclipse IDE Hibernate Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Is this your complete test case? I don't see where you log persistedTime.
     
    Manzar Zaidi
    Ranch Hand
    Posts: 43
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for your reply Paul.
    no, this is not even the test case.
    but I do nothing at all other than what I have there.
    I set a date value in an object property mapped to a SQL Server Datetime column and save the object.
    I realize that if you guys have not observed this anywhere else and dont see any obvious mistake I might be doing, I have to explicitly test this thing and check the possibility of a bug in Hibernate/JDK5/jtds driver.
    Thats something I will do as soon as I get to my workstation tomorrow.
     
    Paul Clapham
    Sheriff
    Posts: 21588
    33
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You should realize that what you are saying is "I ran code A, and I thought there was something wrong with its output, so here's code B which, trust me, is similar." It would be better if you showed us the actual test code that produces that output.
     
    Manzar Zaidi
    Ranch Hand
    Posts: 43
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I am sorry, I think I did not communicate well enough.
    The code I posted is the code that produces the issue. I have a JUnit class testing this piece out, but thats too domain specific to make any point here.
    I hoped to get any 'I have seen it'/'You are doing that things again' kind of comments before I actually Isolated a test for what appears to be the issue.
    I think I will be back with the isolated test soon. Have a good day ahead.
    [ November 15, 2006: Message edited by: Manzar Zaidi ]
     
    Mark Spritzler
    ranger
    Sheriff
    Posts: 17278
    6
    IntelliJ IDE Mac Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Maybe it is just a databsae thing. Meaning how the database stores timestamps changes the Timestamp by a small bit.

    Mark
     
    Rudy Dakota
    Ranch Hand
    Posts: 54
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Manzar,

    Mark is right here. If you search on SQL Server and timestamps, you 'll find that these are not as precise as you 'd like. I am not sure about the exact magnitude, but I think it may be off by one third of a second. More detail can be found in the SQL Server docs, or on the internet.

    Regards,

    Rudy.
     
    Paul Sturrock
    Bartender
    Posts: 10336
    Eclipse IDE Hibernate Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Rudy Dakota:
    Hi Manzar,

    Mark is right here. If you search on SQL Server and timestamps, you 'll find that these are not as precise as you 'd like. I am not sure about the exact magnitude, but I think it may be off by one third of a second. More detail can be found in the SQL Server docs, or on the internet.

    Regards,

    Rudy.



    Do you mean datetime data types? A timestamp is a different thing in SQL Server from an SQL timestamp - it is only really used as a versioning field. SQL Server uses datetime to represent dates instead. It is true that SQL Server datetimes do only have 3 digits of fractoral precision (where Oracle has 9), but are documented to be accurate to within 3.33 miliseconds (or c1/333 of a second). I would be suprised if this added up to a difference of 2 milliseconds in a normal calculation though; if this has been happening in SQL Server I've never noticed it before.

    Though this is by no means conclusive Manzar Zaidi, I work with both Hibernate 2* and 3*, and SQL SQerver 2000 and 2005, and have yet to notice it. Though this may just be because any time calculations we use don't require the same level of precision.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic