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

[Richard Frith-Macdonald]

On 14 Nov 2006, at 23:55, David Ayers wrote:

> 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...

Maybe it did  ... Unfortunately I have no way to tell ... but I have  
just run a test program on MacOS-X and can confirm that the behavior  
there is to return nil if the string does not contain the full date  
specification.

I hope this does not have much (any) impact on gdl2.  I did a quick  
skim of the sqlclient code and see that the date parsing code there  
checks the length of the string in order to decide which format to  
use.  For instance, the postgresql backend uses '%Y-%m-%d' if the  
length is 10, and uses various other formats for other string length/ 
content variations.  In this case at least there are a few situations  
where using the default format could never have worked.