This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Shailesh, getMinutes() is deprecated because you are supposed to use Calendar.get(Calendar.MINUTES) instead. This is the first I hear of the actual precision changing. Do you know where you read that? It seems like a mighty big change for Sun who doesn't like to change semantics.
Shailesh, This really tests what Date.toString() returns. Ideally this would be the same as the precision, but it doesn't have to be.
From the JavaDoc (it's the same in 1.3, 1.4 and 1.5):
A thin wrapper around a millisecond value that allows JDBC to identify this as a SQL DATE. A milliseconds value represents the number of milliseconds that have passed since January 1, 1970 00:00:00.000 GMT.
To conform with the definition of SQL DATE, the millisecond values wrapped by a java.sql.Date instance must be 'normalized' by setting the hours, minutes, seconds, and milliseconds to zero in the particular time zone with which the instance is associated.
So it sounds like Date was never supposed to include the hours/minutes/seconds and it was fixed more recently.
Joined: Aug 15, 2003
Thanks Jeanne Boyarsky ,
your quote is right.
I do this test as folowing: step 1 : execute SQL clause , making field realOffdutyDate value is 2005-01-01 08:06:00.000 step 2 : running program in jdk1.3 and jdk1.4, ang get correct result.
I think the genuine reason is that "A milliseconds value represents the number of milliseconds that have passed since January 1, 1970 00:00:00.000 GMT"