Then, we need to be able to ask: “At what date and time shall we be if we add X working hours to a given date and time considering calendar A and B”…

Of course, I had that kind of class in a pet project of mine. But if Apple could bring some basic NSCalendar it would be a great help (it would have to be core data compatible since we would want to store custom calendars).

Alexander Lamb

best wishes in the classes. can think of a few other ways to do it, but all end up doing essentially the same things already posted.

Oh, in ruby, all you have to do is require 'date'. I wouldn’t be surprised if python has a similar API.

-jcr

First off, when you want to represent a “day”, not a timestamp, NSDate and NSCalendarDate are actually the wrong solution to the problem because they represent a point in time, not an entire day. You really want to calculate some sort of day offset. If you use 1/1/2001 as zero, that corresponds to NSCalendarDate, which makes conversion easy.

If you must use NSCalendarDate (because its easy, because EOF/CoreData supports it, etc.) you have to use Noon, not midnight or DST or timezone issues will cause your date to shift inappropraitely. So day 0 is 1/1/2001 12:00 not 1/1/2001 00:00. If you get a non-noon time, then you’ll have to round it to the nearest day, but ‘ware midnight if you get times from both EST and PST…

In our case, the market closes at 4pm EST, so midnight is far away, but there’s no good answer for what to do at 10pm PST…

So of all the solutions, Bob’s is best because he is independently rounding each date to a day, this is good because this part of the code is the most application dependent. If you’re work day focused, and you’re working with programmers, anything before 7am EST is probably the “previous day’s work”. If you’re doing something else, perhaps midnight makes more sense. Rounding each date separately makes sense, because if you are using midnight, but have dates from different time zones, the round to day code will work correctly in then 1am EST will round to tomorrow, while 10pm PST will round to yesterday.

The real solution is that if you really need days, you need an NSDay class, but I’ve been bitching about that for years (along with the inability of either EOF or CoreData to map a class to a simple data type like integer…)

Throwing out clampToDay and instead just converting to NSCalendarDate and doing a direct calculation with dayOfCommonEra should be perfectly fine, which gets rid most of the messages sent. If you were using NSCalendarDate instead of NSDate to begin with (which you probably should, given how you intend to use them), then there are no intermediate objects at all.

And it ends up producing numerous temporary objects that are later tossed.


NSCalendarDate *clampToDay(NSDate *d) {
// might want to allow for timezone fudge here?
NSCalendarDate *c = [NSCalendarDate dateWithTimeIntervalSinceReferenceDate:[d timeIntervalSinceReferenceDate]];
return [c dateByAddingYears:0 months:0 days:0 hours:-[c hourOfDay] minutes:-[c minuteOfHour] seconds:-[secondsOfMinute]];
}

int stupidHumanDateDifference(NSDate *a, NSDate *b) {
return [clampToDay(b) dayOfCommonEra] - [clampToDay(a) dayOfCommonEra];
}