Ok, then your best bet is probably to explicitly zero out the non-date parts:
Calendar cal = Calendar.getInstance(); cal.setTime(yourDateObject); cal.set(Calendar.HOUR_OF_DAY, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); cal.set(Calendar.MILLISECOND, 0); Donald -------------- Original message ---------------------- From: Robert Enyedi <[EMAIL PROTECTED]> > This is exactly what I've been trying to do. The difficulty which I'm > unable to overcome yet is that the timestamp returned by > java.sql.Date.getTime() is not divisible with the number of miliseconds > in a day (24 * 60 * 60 * 1000). Yet when I create a java.util.Date() > instance with that timestamp, this gives me the 00:00:00 hour of the > desired day (so no time information is in the timestamp). > > This puzzles me, so that's why I decided to ask around. > > Regards, > Robert > > [EMAIL PROTECTED] wrote: > > Java calendar and date objects work in miliseconds but I think that fields > marked as "date" rather than timestamp just have their hour/minute/second > parts > set to 0. Even so, it's fairly easy to roll a timestamp back to 00:00:00. You > can then subtract the Date.getTime() values and divide by 86,400,000 to get > days. > > > > Or am I missing something obvious here? > > > > Donald > > > > -------------- Original message ---------------------- > > From: Robert Enyedi <[EMAIL PROTECTED]> > > > >> Michael, > >> > >> As far as I know, year 0 in MySQL is actually 1 AD. However, it doesn't > >> necessarily matter when that year is when you have the comparability of > >> the results. > >> > >> What matters that this function in combination with its reverse, > >> FROM_DAYS, allows easily for one to compute things like: > >> - are both timestamps in the same day? TO_DAYS(tstamp1) = TO_DAYS(tstamp2) > >> - how many days are between the two dates? TO_DAYS(date1) - TO_DAYS(date2) > >> - what is the date if one adds X days to a specified date? > >> FROM_DAYS(TO_DAYS(date1) + X) > >> > >> I'm not specifically in love with this function either, but what other > >> alternatives does Derby offer to make these computations? > >> > > > > >
