gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] r24082 - in /tests/testsuite/trunk: ChangeLog base/NSC


From: David Ayers
Subject: Re: [Gnustep-cvs] r24082 - in /tests/testsuite/trunk: ChangeLog base/NSCalendarDate/basic.m base/NSCalendarDate/test00.m base/NSCalendarDate/test01.m base/NSCalendarDate/test02.m base/NSDate/create.m
Date: Wed, 15 Nov 2006 00:55:40 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20060926)

Richard Frith-Macdonald schrieb:
> 
> On 13 Nov 2006, at 21:09, David Ayers wrote:
> 
>>
>> --- /tests/testsuite/trunk/base/NSDate/create.m    2006/11/13
>> 16:50:30     24081
>> +++ tests/testsuite/trunk/base/NSDate/create.m    2006/11/13
>> 17:07:10     24082
>> @@ -10,7 +10,7 @@
>>    NSString *val;
>>    NSDate *date1,*date2;
>>
>> -  val = @"2000-10-19";
>> +  val = @"2000-10-19 00:00:00 +0000";
>>    date1 = [NSDate date];
>>    pass(date1 != nil && [date1 isKindOfClass:[NSDate class]],
>>         "+date works");
>>
>> I'm not sure about this change to the test suite...
>>
>> Does this imply that constructing an NSDate with an ISO date without
>> specifing the time is invalid?  I'm afraid that may break some adaptor
>> implementations where the database fields differentiate between dates
>> and timestamps.
> 
> 
> Yes it does mean that it's invalid ... if you want to create a date 
> from a string without the timestamp then the format should not  contain
> a timestamp part.
> Such code would not work on MacOS-X (or with the base library with  the
> appropriate bugfix).  The method initWithString... is explicitly 
> documented to say that the string must match the format.

Well I guess that's a unfortunate result of an evolving API.  It implies
that the date class of an EOAttribute must be an NSCalendarDate (or
subclass thereof) since NSDate does not have the API to specify a
format.  I'm almost certain (but just haven't found to verify) that
OPENSTEP allowed ISO dates without timestamps for NSDate class.  But oh
well...

Cheers,
David






reply via email to

[Prev in Thread] Current Thread [Next in Thread]