calculate "working minutes" between 2 dates

Hello,
I am hoping someone else has thought about a date time calculation i need to
perform.

I would like to be able to calculate the number of "working minutes" between
2 dates, given my working week definition.

Lets say I have a working week definition of Monday through Friday, 9 am to
5 pm.
Date1 = January 1st, 2005 at 8 am
Date2 = February 14th, 2005 at 10 am.
How many "working minutes" between the 2 dates?

How would you code this?

My approach is rather brute force. I break the calculation into 3 parts:
1. Calculate the working minutes in a full week (5 days * 8 hr * 60
minutes= 2400 minutes)
2. Minutes prior to first full week. I basically go day by day and do
date math.
3. Number of full weeks * result from step 1 (2400 most of the time)
4. Minutes after last full week. I basically go day by day and do date
math.

The sum of step 2 + 3 + 4 gives me my answer. I am doing this calculation
alot and it has proven to be a bottleneck.

Any suggestions on making it faster? Please let me know if I can provide
more details. Thanks for all replies in advance!

Thanks,
Dan

[Bruce Wood]

I can't see an obvious alternative to your method.

Are you in a situation where the same date pairs will be passed over
and over, so caching previous answers might have a beneficial effect,
or are the date pairs passed randomly distributed?

If caching would help you, you could create a hash table that contains
previous results... the only thing you would have to come up with would
be an efficient way of getting a key from the two dates to use as a
hash key.

If it's highly likely that the same date pair will be passed many times
in sequence, you could even just have a super-cheap "one off" cache:
the last pair of dates and the answer, and before starting the
calculation check to see if the caller is just re-asking the previous
question.

Good idea.

The application is a discrete event simulation where I am scheduling future
events. Thinking about this, i think many times the first date will be the
same for many consecutive calls to the method, so caching will be great.

Thank you for this valuable tip.

Dan
"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** *************@z 14g2000cwz.goog legroups.com...

I can't see an obvious alternative to your method.

Are you in a situation where the same date pairs will be passed over
and over, so caching previous answers might have a beneficial effect,
or are the date pairs passed randomly distributed?

If caching would help you, you could create a hash table that contains
previous results... the only thing you would have to come up with would
be an efficient way of getting a key from the two dates to use as a
hash key.

If it's highly likely that the same date pair will be passed many times
in sequence, you could even just have a super-cheap "one off" cache:
the last pair of dates and the answer, and before starting the
calculation check to see if the caller is just re-asking the previous
question.

[Bruce Wood]

If the start date is normally the same, then you have two options.

1. Come up with a key scheme for start / end date combinations, and
hash the answers as you compute them. This is the most general scheme,
but its value varies with the cost of computing the hash key: the more
expensive the key, the less effective the cache. Try this:

public struct StartEndDateTim e
{
private static Hashtable _cache = new Hashtable();

private DateTime _startDate;
private DateTime _endDate;

public StartEndDateTim e(DateTime startDate, DateTime endDate)
{
this._startDate = startDate;
this._endDate= endDate;
}

public DateTime StartDate
{
get { return this._startDate ; }
}

public DateTime EndDate
{
get { return this._endDate; }
}

public override int GetHashCode()
{
return this._startDate .GetHashCode() +
this._endDate.G etHashCode();
}

public override bool Equals(object obj)
{
if (obj is DateTime)
{
return Equals((DateTim e)obj);
}
else
{
return false;
}
}

public bool Equals(DateTime otherDate)
{
return this._startDate .Equals(otherDa te._startDate) &&
this._endDate.E quals(otherDate ._endDate);
}

public long GetWorkingDayMi nutes()
{
long result;
obj cacheResult = StartEndDateTim e._cache[this];
if (cacheResult != null)
{
result = (long)cacheResu lt;
}
else
{
... do your math here ...
StartEndDateTim e._cache[this] = result;
}
return result;
}
}

.... then you can use this struct in your application like this:

StartEndDateTim e period = new StartEndDateTim e(startDate, endDate);
long periodMinutes = period.GetWorki ngDayMinutes();

.... and the fact that there's a cache involved is transparent. I would
try this first and then time it to see how performant it is.

2. At least cache the answer to your second part: minutes prior to
first full week, along with the start date from the previous request.
When you enter the routine, you can check the start date against the
previous start date and, if they're the same, use the previous "minutes
prior to first full week" and save yourself that calculation. You can
do the same with the end date. That saves you two of the three most
expensive calculations, leaving you only to calculate the full weeks
minutes each time (until the end date changes, then you have to do the
math again).

You could even come up with a hash table scheme for the end date ->
minutes after last full week answer, and see if the hashing is faster
than the mathematics.

Again, this way you still have to do some math, but you cut back
drastically on the amount you have to do. It's probably less performant
than a full start/end date -> final result caching scheme, but it will
be a big help, nonetheless.