NSNumber date methods not accounting for DST, leap year and other date/calendar oddities #50
Description
The current methods can give a fast approximation, but they can cause some inaccurate/misleading results when you factor in things like daylight savings time and leap year. On a day where the clocks were set back for daylight savings time, one would probably expect @(1).day.ago executed at 2pm to return 2pm the previous day, but since 24 hours ago was 3pm the previous day, that's the time you'll get back with the current implementation.
It looks like the SexyDates project handles that correctly. [NSCalendar currentCalendar] is too slow to call repeatedly without cacheing on iOS 6 and lower, but evidently is now cached in iOS 7. If you're concerned about performance on iOS 6, you can cache the NSCalendar in a thread dictionary.
I'd be happy to work on this if you let me know your thoughts on it before I get started.