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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
