long diff = cur_time.getTime()-t.getTime();
}
Then I am converting it to seconds, minutes and hours, but the problem is time that we get from cur_time.getTime() has more digits than time that we get from t.getTime(), so it is always greater than t.getTime() even when it is not.

>
Then I am converting it to seconds, minutes and hours, but the problem is time that we get from cur_time.getTime() has more digits than time that we get from t.getTime(), so it is always greater than t.getTime() even when it is not.
. . .
Tell me the solution of this problem.
>
The simplest solution is to prevent this from happening:

time that we get from cur_time.getTime() has more digits than time that we get from t.getTime()

But since it is YOU that is creating the 'more digits' the solution is: DON'T DO THAT! ;)

That 'date.getTime()' call gets milliseconds per the API for java.util.date
http://docs.oracle.com/javase/6/docs/api/java/util/Date.html
>
long getTime()
Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.
>
So BEFORE you use that 'millisecond' value to create your reference 'java.sql.Time' instance just convert it to the number of 'digits' that you want. If you want seconds divide it by 1000

java.util.Date date = new java.util.Date();
long mySeconds = (long) (date.getTime() / 1000L); // convert the milliseconds to seconds
java.sql.Time cur_time = new java.sql.Time(mySeconds); // now your instance will have seconds and not milliseconds

Now you can just compare 'seconds' to 'seconds'.

That 'simple' solution costs you one line of code and is very easy for anyone reading your code to understand.

The data store stores a timestamp in a form with a precision that is specific to the database.
Java uses timestamps with a precision that is specific to Java.

Assuming that they are the same is a bad idea. Assuming they will remain the same is a bad idea.

If you want an exact match then then you must first understand how the data was stored in the database.
And it will ONLY work if the stored value was cleaned before it was stored. And even then it is a bit suspect. (Cleaned means that the value was adjusted, before storage to insure that the normal precision of the database would not be a factor when doing queries from external sources.)

If it wasn't cleaned then you MUST use a range query. You must create a min and max value and look for values between those two.