D
D
dshvechikov2013-01-09 12:01:27
MySQL
dshvechikov, 2013-01-09 12:01:27

Part of java.util.Date milliseconds is trimmed when saving to database

In general, such a problem: there is hibernate, a mysql database, there is a certain class with a java.util.Date field. There is something like this test:

assertEquals(objectService.findById(object.getId()), object);

The test fails.
The hashCode and equals methods are overloaded.

I began to understand why and what is wrong. As a result, before saving to the database, the date field returns 1357721424351 milliseconds, and after the object is pulled out of the database, the same field returns 135721424000. the last 3 digits are cut off

Actually, maybe there are ideas who is to blame and what to do?

Answer the question

In order to leave comments, you need to log in

2 answer(s)
I
ivnik, 2013-01-09
@dshvechikov

Probably the database is to blame. In the SQL standard (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt):

There are three classes of datetime data types defined within this
International Standard:
— DATE — contains the <datetime field>s YEAR, MONTH, and DAY;
- TIME - contains the <datetime field>s HOUR, MINUTE, and SECOND;
and
- TIMESTAMP - contains the <datetime field>s YEAR, MONTH, DAY,
HOUR, MINUTE, and SECOND.


Those. milliseconds are not stored.

A
Artur Smirnov, 2013-01-09
@wisd

You say that the hashcode and equals methods are overloaded, so you need to overload them more and compare dates with an accuracy of seconds

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question