Re: Problem with date and time columns both bound to the same date attribute
Re: Problem with date and time columns both bound to the same date attribute
- Subject: Re: Problem with date and time columns both bound to the same date attribute
- From: Matt Neuburg <email@hidden>
- Date: Tue, 25 Dec 2007 10:42:37 -0800
- Thread-topic: Problem with date and time columns both bound to the same date attribute
On Sun, 23 Dec 2007 00:39:13 -0700, Andrew Madsen
<email@hidden> said:
>I've found something that I think is a bug (and will file with Apple)
>but in the meantime I'd like to know if anyone has a reasonable
>workaround. I've got a Core Data app and each entity has a date
>attribute. I have a table that shows the entities with a column for
>each attribute. I have a column for the date and another column for
>the time. These are both bound to the same date attribute. Each has
>a formatter that makes it so the date column displays the date and the
>time column displays the time. The problem is, if you edit an
>entity's date by double clicking on the date column then entering a
>new date, the time gets reset to 00:00 and the same thing happens if
>you edit the time (date gets reset to 1/1/1970 or whatever). I've
>posted a very simple example project here:
http://www.andrewmadsen.com/misc/TimeAndDate.zip
>Anyway, I can't see why this behavior would be desired, so I think
>this is in fact a bug.
Not everyone would necessarily agree, though. It doesn't seem like a bug to
me.
You seem to be assuming that just because a formatter is showing me only the
time part of a date, setting the value in the formatted cell will set only
the time part of the date. That is (evidently) an unwarranted assumption.
The formatter may be *showing* me only the time part of the date, but when I
set the value I am setting the *whole* date, the underlying date value of
the cell. I didn't enter a date part (nor can I), so a default date is
assumed. The entity's date attribute is bound to that, so it takes on that
default date. That seems to me to be correct behavior.
One obvious way to handle the situation you have got yourself into might be
to have two date attributes in your entity, one for holding the date part,
another for holding the time part. When your app for any reason wants to
know the full date-time it simply combines the date part of the first
attribute with the time part of the second attribute - knowing that the
remaining parts (the time part of the first attribute and the date part of
the second attribute) are "junk DNA".
Another possibility might be to use some code to run interference in the
binding, so that when, for example, the time-part cell offers a new value,
the binding modifies this to take account of the existing date value in the
entity's attribute. But the first way sounds a lot easier to me.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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