On Jan 5, 2010, at 1:35 pm, Kyle Sluder wrote: > On Tue, Jan 5, 2010 at 1:23 PM, mmalc Crawford <mmalc_li...@me.com> wrote: >> An NSDate object represent a single point in time -- you can think of it >> basically as a wrapper for an NSTimeInterval from the reference date. If >> you want to create components from the date, then you must do so with >> respect to a particular calendar *and time zone*... This is of course >> possible, but then you have to be careful about always using the same >> combination of calendar and time zone to create the components and recreate >> the date from the components. > > I believe that Quincey's argument is that it is conceptually > inaccurate in most cases to think of a point in time as simply an > interval from a reference date. I agree that in contexts where words > like "today" are meaningful, he's probably right. Especially in > calendaring/scheduling apps. Given the number of people who struggle > with the concept of daylight saving time, I am not surprised that I > have yet to meet a non-technical person who could conceptualize a > "point in time" independently of a calendar system. > I'm not sure what the point is here, though? 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.
mmalc _______________________________________________ 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
