Is this necessary? The result of Calendar.getTime().getTime() is a long representing the number of milliseconds since the epoch where the epochal point is defined as Jan 1, 1970 00:00:00.000 GMT. This already normalizes for GMT and for daylight savings. The calendar class essentially provides various filters about this value to transform the time into something human understandable (this includes accomodating daylight savings and timezone offsets).
I'm not sure why we'd want to further offset the milliseconds value with timezone and daylight savings offset - the original numbers are already normalized to the same point in time. I agree that there's utility to be found in things like getDaysBetween (just believe this implementation behaves incorrectly), but if I recall, there was, at some point (if not today) a Duration class being developed to represent durations. I'm not sure if anyone is still working on it, but it seems that this might be the way to go - define Durations and how to convert between durations and java.util.Date differences. -AMT -----Original Message----- From: Inger, Matthew [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 7:34 AM To: 'Jakarta Commons Developers List' Subject: [lang] possible DateUtils method public static final long MILLIS_IN_DAY = 1000*60*60*24; public long getDaysBetween(Calendar c1, Calendar c2) { long c1Normalized = c1.getTime().getTime() + c1.get(Calendar.ZONE_OFFSET) + c1.get(Calendar.DST_OFFSET); long c2Normalized = c2.getTime().getTime() + c2.get(Calendar.ZONE_OFFSET) + c2.get(Calendar.DST_OFFSET); long diff = c1Normalized - c2Normalized; long numDays = diff / MILLIS_IN_DAY; return numDays; } A common mistake most people make is to ignore daylight savings time when trying to compute the number of days between two Calendar dates. If you cross the DST boundary when the clock jumps forward, just subtracting the date objects and dividing will end up giving you an answer that is off by 1 day. This happens because the clock jumps ahead, and 00:00 EDT is actually 11:00 EST on the previous day, so the number of hours is off by 1, and thus the calculation doesn't end up working properly. The other thing i'm doing here is to convert to GMT time, allowing for the two Calendar objects to have different timezones. We could have similar methods for getHoursBetween and so forth. Months would be a bit more complicated of an algorithm. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
