Re: NSDate without time portion
Re: NSDate without time portion
- Subject: Re: NSDate without time portion
- From: Quincey Morris <email@hidden>
- Date: Tue, 5 Jan 2010 15:43:21 -0800
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 (email@hidden)
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:
This email sent to email@hidden