On 2006-06-30, at 13:25:44, Stuart A. Malone wrote:
It's just that Sync Services requires a NSCalendarDate for any
database fields of type "calendar date", and neither CFDate nor
NSDate qualify because they do not include time zone information.
The toll-free bridging works fine -- it's Sync Services that is
being picky.
I can't speak directly to your problem but as of 10.4, there is
CFCalendar.h in CoreFoundation.
A CFCalendarRef (or bridged NSCalendar) is not the same thing as an
NSCalendarDate. A "calendar date" is a date that "performs date
computations based on the Gregorian calendar" and includes time zone
information; NSCalendarDate predates (ahem, sorry) NSCalendar by
about a decade. See the documentation for NSCalendarDate for more
information.
It makes sense that an API that expects to deal with NSCalendarDate
objects would not deal properly with NSDate (or bridged CFDateRef)
objects; an instance of a parent class cannot often be substituted
for an instance of a subclass.
For future reference, here's a discussion of toll-free bridged Core
Foundation types and Cocoa classes as of Mac OS X 10.4:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
