On Jan 5, 2010, at 13:43, mmalc Crawford wrote:

> I'm not sure what the point is here, though?

Well, taking what's likely a rhetorical question literally, the point (at least 
my point) is that switching from dates represented by conceptual structures 
such as NSDateComponents + NSCalendar + time zone (which is an important 
complication we were ignoring till you pointed that out) to dates represented 
by NSDate objects (which are "really" times, not dates) *isn't* going to 
simplify the programmer's task, and will probably complicate it.

> It's the job of the application to present to the user a representation of a 
> date that they can understand. It's the job of the programmer to interpret 
> that unambiguously such that it can be stored and recreated -- which is the 
> issue here. Talking about date components in the abstract as if any date can 
> arbitrarily be reduced to a collection of components without reference to any 
> other context (the calendar and time zone) is misleading.

Yes, there's no answer to the question without reference to what piece of 
application functionality (what programming task) is under consideration. Dates 
with times, dates without times, dates relative to a pre-determined calendar 
and time zone, dates relative to the user's locale, dates relative to a service 
provider's locale, dates kept transiently in memory, dates written to 
persistent storage, these are all things that have to be settled on a case by 
case basis, and multiple approaches may need to co-exist in a single 
application.

I actually believe that Apple thought this through very carefully (twice -- 
once producing NSCalendarDate, which presumably wasn't a satisfactory solution, 
and once producing NSCalendar + NSDateComponents, which we hope is), and to 
ignore or bypass NSCalendarDate simply wastes the effort that was put into it. 
And risks Doing It Wrong™.

But that's probably too much soapbox time on my part, so I'll climb down now.


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to