Amila Suriarachchi wrote:
...
On 2/16/07, * Dennis Sosnoski* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Larry,
You're correct on your assumptions, that if a Calendar is being
returned
it should have a consistent time value and time zone. In this case the
time zone of the Calendar should be set to UTC. That said, there are
some seriously warped issues involved - Calendar *always* works with
time zones, while xsd:dateTimes either use UTC times or times with no
zone information (where the latter have basically a half-day
uncertainty
factor).
Can you pleas explain this bit? in xml spec the lexical
representation of the datetime is
'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)? and
this (zzzzz)? part is either be Z (means GMT) or the actual time zone
(eg +0530)
The offset is not a time zone - it's just an offset. The problem is that
when you try translating this into a Java Calendar you use a *real* time
zone, and in Java terms this means that it has associated dates when
daylight savings time is in effect and such. The xsd:dateTimes don't
have this implication - the +/- value is only an offset from GMT for the
particular values supplied.
IMHO this is another example of the stupidity of schema. There's no
point in allowing offsets in the representation when they're eliminated
in the actual value, and it just creates more opportunity for confusion.
xsd:dateTimes do not support time zones in the Java sense at all.
Can't we use the simpleDateFormatter to parse the dates correctly with
timezones?
Dennis can you please check the logic I have used in convertToDateTime
method in org.apache.axis2.databinding.utils.ConverterUtil to parse
the date?
If you want to convert xsd:dateTimes to a Calendar, you can do so
correctly *only* if the dateTime uses an offset or a UTC (Z) value (of
course, the same limitation applies in converting to java.util.Date
values - it takes a structure like the
javax.xml.datatype.XMLGregorianCalendar class to really represent an
xsd:dateTime in all its confused complexity). In this case, the way to
handle things is to force the Calendar to use UTC and convert the value
on this basis.
I don't honestly know if you can easily do this using SimpleDateFormat.
This code, like all the standard Java date/time handling, is riddled
with inconsistencies and side-effects, so it's very difficult to say how
to make it behave in a particular way. JiBX uses its own code for
parsing dateTimes and related values, which you can find in the
org.jibx.runtime.Utility class:
http://jibx.cvs.sourceforge.net/jibx/core/build/src/org/jibx/runtime/Utility.java?view=markup
It's BSD licensed, but I'll willingly grant you permission to use the
code in Axis2 and convert to Apache license if you want. The JiBX code
uses Dates as the equivalent to xsd:dateTime values, but a Calendar is
basically just a wrapper around a Date that adds time zone information.
If you create the Date value first you should be able to create a
Calendar using UTC and then call the Calendar.setTime() method to set
the Calendar correctly.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
