Question about laterDate: and earlierDate:

  • Hi-

    I'm a big fan of laterDate: and earlierDate:.

    I use them with NSCalendarDate objects even though the methods belong
    to NSDate because NSCalendarDate is a subclass of NSDate and so I
    should be able to it seems.

    And it seems to work fine, but I do get a compiler warning of:
    "warning: passing argument 1 of 'setStartTime:' from distinct
    Objective-C type"

    Here is my code example:

    [selectedOS setStartTime:[testedStartTime laterDate:now]];    //this
    line gives the warning

    - (void)setStartTime:(NSCalendarDate *)newStartTime        //this is the
    method I am calling
    {
    [newStartTime retain];
    [startTime release];
    startTime = newStartTime;
    }

    startTime is an NSCalendarDate ivar.
    testedStartTime is an NSCalendarDate object locally defined.
    now is an NSCalendarDate ivar.

    So the compiler seems like it's mad that [testedStartTime
    laterDate:now] returns an NSDate maybe instead of an NSCalendarDate?
    Do I have to use id in my setStartTime: method to prevent this
    warning? It seems like I shouldn't have to due to NSCalendarDate
    having inherited the methods from NSDate...

    Thank you in advance
  • Indeed the compiler has spotted that -laterDate returns an NSDate
    rather than NSCalendarDate. Can you be sure that an actual
    NSCalendarDate object is being returned? If so, you could something
    like this:

    [selectedOS setStartTime:(NSCalendarDate *)[testedStartTime
    laterDate:now]];

    However, I should point out that that isn't particularly good practice
    really. If you can afford to only target 10.4 and later, you should
    really use NSDate and NSCalendar rather than NSCalendarDate.

    Mike.

    On 16 Oct 2007, at 13:39, Paul Bruneau wrote:

    > Hi-
    >
    > I'm a big fan of laterDate: and earlierDate:.
    >
    > I use them with NSCalendarDate objects even though the methods
    > belong to NSDate because NSCalendarDate is a subclass of NSDate and
    > so I should be able to it seems.
    >
    > And it seems to work fine, but I do get a compiler warning of:
    > "warning: passing argument 1 of 'setStartTime:' from distinct
    > Objective-C type"
    >
    > Here is my code example:
    >
    > [selectedOS setStartTime:[testedStartTime laterDate:now]];    //this
    > line gives the warning
    >
    >
    >
    > - (void)setStartTime:(NSCalendarDate *)newStartTime        //this is the
    > method I am calling
    > {
    > [newStartTime retain];
    > [startTime release];
    > startTime = newStartTime;
    > }
    >
    > startTime is an NSCalendarDate ivar.
    > testedStartTime is an NSCalendarDate object locally defined.
    > now is an NSCalendarDate ivar.
    >
    > So the compiler seems like it's mad that [testedStartTime
    > laterDate:now] returns an NSDate maybe instead of an NSCalendarDate?
    > Do I have to use id in my setStartTime: method to prevent this
    > warning? It seems like I shouldn't have to due to NSCalendarDate
    > having inherited the methods from NSDate...
    >
    > Thank you in advance
  • On Oct 16, 2007, at 9:35 AM, Mike Abdullah wrote:

    > Indeed the compiler has spotted that -laterDate returns an NSDate
    > rather than NSCalendarDate. Can you be sure that an actual
    > NSCalendarDate object is being returned? If so, you could something
    > like this:
    >
    > [selectedOS setStartTime:(NSCalendarDate *)[testedStartTime
    > laterDate:now]];

    Thank you Mike for your reply. I see that you are "casting" the
    response from -laterDate: to be an NSCalendarDate (if I am using the
    incorrect term, please excuse me because I come from a different Mac
    dev environment than most)

    I can be sure of the type that is returned but I agree this isn't the
    best thing. I still wonder why is -laterDate: returning an NSDate.
    Isn't it true that since NSCalendarDate is a subclass of NSDate it
    should have full use of the superclass' methods without this kind of
    hassle? We don't get the same problem when we use methods from
    NSArray in our NSMutableArrays do we?

    > However, I should point out that that isn't particularly good
    > practice really. If you can afford to only target 10.4 and later,
    > you should really use NSDate and NSCalendar rather than
    > NSCalendarDate.

    I can afford to target 10.4 since this app is for a single user under
    my control, but I like the methods that exist in NSCalendarDate. I
    heard in Big Nerd Ranch's Cocoa Boot Camp last July that people were
    turning away from NSCalendarDate due to localization concerns IIRC.
    Is there some documentation from Apple that can fully explain to me
    why I shouldn't use NSCalendarDate? I have no such localization
    concerns in my case but am still interested.

    Thanks again
  • On 16 Oct 2007, at 14:59, Paul Bruneau wrote:

    > On Oct 16, 2007, at 9:35 AM, Mike Abdullah wrote:
    >
    >> Indeed the compiler has spotted that -laterDate returns an NSDate
    >> rather than NSCalendarDate. Can you be sure that an actual
    >> NSCalendarDate object is being returned? If so, you could something
    >> like this:
    >>
    >> [selectedOS setStartTime:(NSCalendarDate *)[testedStartTime
    >> laterDate:now]];
    >
    > Thank you Mike for your reply. I see that you are "casting" the
    > response from -laterDate: to be an NSCalendarDate (if I am using the
    > incorrect term, please excuse me because I come from a different Mac
    > dev environment than most)

    That is the correct term indeed
    >
    >
    > I can be sure of the type that is returned but I agree this isn't
    > the best thing. I still wonder why is -laterDate: returning an
    > NSDate. Isn't it true that since NSCalendarDate is a subclass of
    > NSDate it should have full use of the superclass' methods without
    > this kind of hassle? We don't get the same problem when we use
    > methods from NSArray in our NSMutableArrays do we?

    You get basically the same behaviour with NSArray. e.g.

    - (NSArray *)objectsAtIndexes:(NSIndexSet *)indexes

    It's just not normally an issue since you don't generally care about
    getting back a mutable array specifically.
    >
    >
    >> However, I should point out that that isn't particularly good
    >> practice really. If you can afford to only target 10.4 and later,
    >> you should really use NSDate and NSCalendar rather than
    >> NSCalendarDate.
    >
    > I can afford to target 10.4 since this app is for a single user
    > under my control, but I like the methods that exist in
    > NSCalendarDate. I heard in Big Nerd Ranch's Cocoa Boot Camp last
    > July that people were turning away from NSCalendarDate due to
    > localization concerns IIRC. Is there some documentation from Apple
    > that can fully explain to me why I shouldn't use NSCalendarDate? I
    > have no such localization concerns in my case but am still interested.

    Well the localization issue is simply that NSCalendarDate only
    supports the Gregorian calendar. NSCalendar works by splitting that
    localization-specific code out into a separate class so you can
    support multiple calendars. One other good reason is that Core Data
    will only store NSDates, not NSCalendarDates.
    >
    >
    > Thanks again
  • On Oct 16, 2007, at 11:10 AM, Mike Abdullah wrote:

    > You get basically the same behaviour with NSArray. e.g.
    >
    > - (NSArray *)objectsAtIndexes:(NSIndexSet *)indexes
    >
    > It's just not normally an issue since you don't generally care
    > about getting back a mutable array specifically.

    I understand now, thank you.

    > Well the localization issue is simply that NSCalendarDate only
    > supports the Gregorian calendar. NSCalendar works by splitting that
    > localization-specific code out into a separate class so you can
    > support multiple calendars. One other good reason is that Core Data
    > will only store NSDates, not NSCalendarDates.

    OK I just deleted the word "Calendar" everywhere it appeared in my
    code and it runs great so I guess I wasn't that in love with
    NSCalendarDate after all. I just had to change one method to a
    slightly different one in a few areas. Nearly rhetorically, I ask: Is
    it expected that Apple is going to deprecate NSCalendarDate?

    Thanks for the nudge. I'm trying to do things the Right Way™
  • On 16 Oct 2007, at 16:48, Paul Bruneau wrote:

    > On Oct 16, 2007, at 11:10 AM, Mike Abdullah wrote:
    >
    >> Well the localization issue is simply that NSCalendarDate only
    >> supports the Gregorian calendar. NSCalendar works by splitting
    >> that localization-specific code out into a separate class so you
    >> can support multiple calendars. One other good reason is that Core
    >> Data will only store NSDates, not NSCalendarDates.
    >
    > OK I just deleted the word "Calendar" everywhere it appeared in my
    > code and it runs great so I guess I wasn't that in love with
    > NSCalendarDate after all. I just had to change one method to a
    > slightly different one in a few areas. Nearly rhetorically, I ask:
    > Is it expected that Apple is going to deprecate NSCalendarDate?

    I have no idea if it is going to be deprecated, but seeing as
    NSCalendar was new to 10.4 I would imagine that it will eventually be.
  • On Oct 16, 2007, at 7:35 AM, Mike Abdullah wrote:

    > If you can afford to only target 10.4 and later, you should really
    > use NSDate and NSCalendar rather than NSCalendarDate.

    Unless you need to encapsulate time zones within dates, in which case
    only NSCalendarDate will do.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Oct 16, 2007, at 7:59 AM, Paul Bruneau wrote:

    > I heard in Big Nerd Ranch's Cocoa Boot Camp last July that people
    > were turning away from NSCalendarDate due to localization concerns
    > IIRC. Is there some documentation from Apple that can fully explain
    > to me why I shouldn't use NSCalendarDate? I have no such
    > localization concerns in my case but am still interested.

    Having worked with both:

    NSCalendarDate is tied to the Gregorian calendar. Its calendar
    component methods are very fast (NSCalendar's methods are much
    slower, especially on PPC Macs for some reason), but it doesn't
    support the Julian calendar (which was used prior to October 1582),
    and doesn't properly support BC dates.

    NSCalendar properly supports the Gregorian and Julian calendars, plus
    a number of other world calendars. It also supports multiple eras,
    which is particularly important to the Japanese calendar. Its only
    real problem is it's slow, and it has some interesting bugs as of OS
    X 10.4.10.

    Right now there are only two reasons why NSCalendarDate is still
    around: Backward compatibility, and the fact that NSCalendarDate can
    encapsulate time zones (NSDate can't, and NSCalendar assumes all
    dates are in the same time zone). If you don't care about those two
    things, and you don't mind its slowness, than NSCalendar is probably
    for you.

    Nick Zitzmann
    <http://www.chronosnet.com/>
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today