perhaps I should have been more precise. Consider the following
SDO attribute defined in xsd:
<attribute name="validTo" type="date"></attribute>
My first question can be put like this:
The Java type for the SDO type Date is java.util.Date. Can I generate
SDOs with java.util.Date typed properties using XSD2JavaGenerator,
instead of being forced to do implicit conversions from/to String
using the getDate()/setDate() accessors?
My second question is: The spec says in section 8.1 that the String
representation of a date is always this:
'-'?yyyy'-'mm'-'dd'T'hh':'mm':'ss('.'s+)?'Z'?
I would have thought this applies to simple dates (only year, month,
days, no hours etc.) as well (cf. section 8.1.2) However, when I obtain
such a date, set it in the SDO and look at the string value using Tuscany
1.6, I get something completely different:
// obtain a date with year, month, day only in default TZ
Calendar cal = new GregorianCalendar();
cal.set( 2010, Calendar.OCTOBER, 15, 0, 0, 0 );
cal.set( Calendar.MILLISECOND, 0 );
Date date = cal.getTime();
sdo.setDate( "validFrom", date );
String str = sdo.getValidFrom();
Then str = 2010-10-15[ MESZ]
Is this is a bug or do I misread the spec?
-- Sebastian
> -----Original Message-----
> From: Millies, Sebastian [mailto:[email protected]]
> Sent: Thursday, October 14, 2010 10:36 PM
> To: [email protected]
> Subject: SDOs and xsd date
>
> Hello there,
>
> I have an elementary question: when I define a date attribute like
> this:
>
> <attribute name="validTo" type="date"></attribute>
>
> and generate an SDO from it using XSD2JavaGenerator, the attribute
> ends up String-valued. Is there a way to generate a java.util.Date or
> some such as the attribute type?
>
> If not, I guess DataHelperImpl.toDateTime(Calendar) should return a
> String
> compatible with the XML Schema dateTime. But what about simple date?
> And if I need to use some date and time api to manipulate the dates,
> I'd need to know the exact format of the returned strings, including
> how time zones are represented. The spec seems a bit vague here.
>
> -- Sebastian
