range = [[NSCalendar currentCalendar] rangeOfUnit:NSWeekdayCalendarUnit
inUnit:NSWeekCalendarUnit
forDate:date];

This will do what Tom was expecting. For a Gregorian calendar, it should always return {1, 7}. Still not useful for getting the starting day relative to the month. In such a case you can create an NSCalendarDate, get its -dayOfWeek and then create a new date by subtracting that number of days from the original date.

In any case, going to amend the article to tell people to read the comments.

I think the range currently returned is just as inaccurate though. If you have (28, 29, 31, 1, 2, 3, 4), the range {1, 31} implies that 5, 6, 7..27 are in that range, which they aren’t. It’s the similar to the logic that {28, 7} implies numbers greater than 31.

In some ways, I think it might have been better if Apple treated this as an undefined computation and returned NSNotFound.

What about using:

-[NSCalendar maximumRangeOfUnit:]

with kCFCalendarUnitWeekday.

That’s 10.4.

The only use I can think is for user interface validation/limitation. For example, let’s say you’ve specified a year and month, you could use this function to determine the range of values that day can take within that month. I can’t think of a use where the larger unit is NSCalendarUnitWeek though. Maybe it’s useful in non-Gregorian calendars.

If you want to work out the start date and length of a week, I’m sure you’ve probably spotted the Leopard only:

-[NSCalendar rangeOfUnit:startDate:interval:forDate:]

method. There’s also

-[NSCalendarDate years:months:days:hours:minutes:seconds:sinceDate:]

which might be useful for your purposes.

The example where you pass 34 for the day is clearly a special case and I certainly wouldn’t rely on it, especially since the documentation says that valid values are 1 through 31.

>And additionally, your logic doesn’t explain the 31 days in a year.
>How is that supposed to be desired behavior?

Within a particular year, the day can take the value 1 to 31. It’s not saying that there’s 31 days in a year.

> Look, at this point, there is no way you can convince me that you’re way
> makes more sense or is in any way more useful.

I’m not trying to convince you that it makes more sense or is any way more useful. I’m just explaining to you the way it is, or trying to at least.

> And if you can’t see the obvious logical expectation that everybody else has
> (ask around by just showing them the method description and see what they
> say) then there’s little point in me trying to convince you.

Of course I can see the logical expectation that everyone else has. What you expected and want is clearly more useful which is presumably why Apple added a method for that purpose.

I’m still stuck hardcoding 7 days in a week. Chances are slim that this will come back to haunt me but it defeats the purpose of abstracting out the calendar if you can’t rely on it for information like this.

But, even using your logic, it doesn’t hold up. Try this:

date = [NSCalendarDate dateWithYear:2008 month:1 day:34 hour:0 minute:0 secon\
d:0 timeZone:nil];
NSLog(@”Date : %@”, date);


34 is an acceptable value for day and NSCalendarDate is smart enough to know that extends into the next month. Plus, the range does not necessarily suggest that the numbers 32-34 are the actual “labels” for the days. The range says the 7 days starting from the 28th.

And additionally, your logic doesn’t explain the 31 days in a year. How is that supposed to be desired behavior?

Look, at this point, there is no way you can convince me that you’re way makes more sense or is in any way more useful. And if you can’t see the obvious logical expectation that everybody else has (ask around by just showing them the method description and see what they say) then there’s little point in me trying to convince you.

What the function does is ask this (in the case where you pass NSDayCalendarUnit and NSWeekCalendarUnit):

“What is the smallest range that will cover the possible values of day for the week on the date I specify?”

What the function does *not* do is tell you “what is the first day of that week and how long is it?”.

So, take 31 Jan 2008 for example. The week starts on 27 Jan, so the day can take the values, 27, 28, 29, 30, 31, 1, 2. The smallest range that covers those values is clearly {1, 31} which is what you get on Leopard.

I realise that you want the function to work differently, but I’m afraid it doesn’t and it’s perfectly logical the way it works. There is a bug on Tiger because by returning { 28, 7 } it’s suggesting that the day will always fall into that range i.e. 28-34.

I’ll bet your Mac Pro that Apple tell you it works as expected.

Leopard reports {1, 31}. Now, even if you take that 1 to be the first of the next month, 31 still doesn’t make sense under your logic because the next month is February and it only has 28 days. But all that is moot as the week does not start on the first for either Jan or Feb of 2007. In addition, back to the original bug I cited, there is no good reason why the week, which was accurately reported as being 7 days long in the other weeks (and in every week on Tiger) is reported as being 31 days. Of what possible use is that to the developer? It seems like you are trying to argue the “logic” of the bug. I just don’t see how you can argue this as being logical. It may be an explanation of why it’s happening, but that doesn’t mean it’s correct.

@tom: The code above only produces a result of 1-7 if the first day happens to be the first day of the month. The reason the length differs is for the reason I outlined earlier: because the day wraps when a week straddles a month boundary. If you look at the week at the end of this month, you’ll find you get {1, 29} back.