commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <>
Subject RE: [lang] possible DateUtils method
Date Mon, 24 Nov 2003 23:27:23 GMT
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.


-----Original Message-----
From: Inger, Matthew [] 
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) +

	long c2Normalized = c2.getTime().getTime() + 
                          c2.get(Calendar.ZONE_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:
For additional commands, e-mail:

View raw message