thanks for pointing that out – I did overlook that long sentence on page 69
ending
with the important word “respectively”.
However, with regard to YearMonthDay, the spec says that its string
representation is:
'-'?yyyy'-'mm'-'dd zz?
with zz time zone (('+'|'-')hh':'mm)|'Z' where hh time zone hour, mm time zone
minute.
So does not the return value of getValidTo()in my example, which is the String
2010-10-15 MESZ, have a wrong time zone designation?
Another question: In what way would using type="sdo:Date" be any worse than
obtaining
a date using the getDate(“validTo”) accessor? And there seems to be no other
way to get
the date, short of parsing the string representation yourself into some other
Java type of your
choice.
-- Sebastian
From: Frank Budinsky [mailto:[email protected]]
Sent: Friday, October 15, 2010 3:59 PM
To: [email protected]
Subject: Re: SDOs and xsd date (bug?)
Sebastian,
Your example:
<attribute name="validTo" type="date"></attribute>
is using XSD type "date", which is not the same as SDO type "Date". There are
many different "date information" types in XML Schema (e.g., xsd:date,
xsd:dateTime, xsd:GYear, xsd:gYearMonth, etc.). If you look at the SDO spec,
you'll see that xsd:date maps to SDO type YearMonthDay, not Date. The
instanceClass (Java class) for all the XSD-mapped date types is String because
java.util.Date has timezone-related problems).
If you want time information, perhaps you should model your attribute like this:
<attribute name="validTo" type="dateTime"></attribute>
If you really want to use java.util.Date as the instanceClass, you would need
to use SDO type Date:
<attribute name="validTo" type="sdo:Date"></attribute>
I wouldn't recommend it though, because of the TZ issues.
Frank
"Millies, Sebastian" <[email protected]> wrote on 10/15/2010
06:33:04 AM:
> [image removed]
>
> Re: SDOs and xsd date (bug?)
>
> Millies, Sebastian
>
> to:
>
> user
>
> 10/15/2010 06:35 AM
>
> Please respond to user
>
> 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
