The reason we were using util.Date is that it provides as much precision
as is easily available in Java. I guess some db's have more precision,
but we usually avoid such database specific features. The only feature
Timestamp offers over util.Date is that it can hold timestamps with
nanosecond precision. I guess it might not hurt to use the
sql.Timestamp, since it is possible an application may need the extra
precision.
The reason to use util.Date is to use Village to convert the Timestamp,
so that the milliseconds get inserted into the main long that backs the
util.Date. Unfortunately, I think Village is not doing this, so there
may be even more reason to change.
[EMAIL PROTECTED] wrote:
>
> Hello,
> * DATE | java.sql.Date | java.util.Date
> * TIME | java.sql.Time | java.util.Date
> * TIMESTAMP | java.sql.Timestamp | java.util.Date
> *
> * -------------------------------------------------------
>
> public static final String TIMESTAMP_OBJECT_TYPE = "new Date()";
> public static final String TIMESTAMP_NATIVE_TYPE = "Date";
> public static final String TIMESTAMP_VILLAGE_METHOD = "asDate()";
Actually the Village method should be "asUtilDate()". Then Village
should be patched so that it does not throw away the milliseconds when
converting a Timestamp to a util.Date.
This would be the fix that I would prefer.
But if you want to persuade me otherwise, go ahead. I guess we could
provide a utility method that would properly compare/convert a util.Date
with/to/from a Timestamp.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
