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 12:23:09 -0800
On Jan 5, 2010, at 11:31, David Duncan wrote:
>> However Core Data models "dates" using NSDate. If you needed to model dates without times in Core Data (and be able to sort/filter on them) what would you do?
>
>
> The typical approach is to normalize your dates to a specific time before storing them.
On Jan 5, 2010, at 11:41, Nick Zitzmann wrote:
> Normalize the time component of the date. One idea is to use 12 PM GMT as a constant time, since then the date will be the same date everywhere in the world - except in New Zealand, Fiji, Kiribati, Samoa, & other states in the GMT+12/13 neighborhood, so you'll have to translate for them. iCal does this when synchronizing calendar dates.
I'll say this part again, and keep saying it till someone actually tells me I'm wrong:
Firstly, you can't *in general* normalize to a specific time, because you can't in general know that the time exists on every date. With the daylight savings time system used in America, for example, not every date has a 2:30 am, and some dates have 2 of them. Whatever time you pick is a *cultural* assumption that can't be relied upon for every date in every calendar system -- unless Apple has documented somewhere the API contract that every calendar system implementation in Mac OS *shall* have a midnight or a noon (say).
Secondly, there's no safe way to normalize to a specific time without using NSDateComponents. If you have a NSDate that represents 8 am on a certain day, you can't just subtract 8 hours to get midnight. (Think of daylight savings again for a counterexample. Or the occasional leap second.)
Thirdly, however you normalize the time, it's certainly not true that differences between normalized dates are multiples of precisely 24 hours, or of whole days. Comparisons will be fine, but elapsed days computations will be wrong.
I don't see any way to avoid NSDateComponents. Using them, you can reconstruct normalized dates (which would be normalized, therefore, to a unique time on each date, but not necessarily the same time on all dates), or you can just work with the Y-M-D (or even just Y-D) components directly, as integers.
(Well, date strings might be a viable alternative, but it's not obvious that's any more elegant overall.)
_______________________________________________
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