That's precisely my point - the dateTime value is always in UTC, which is precisely what a Date is. I should probably have stated this more clearly. The offset is taken into account when interpreting the value of the dateTime, but the offset itself is then discarded - only the resulting instant of UTC is significant.Dennis Sosnoski <[EMAIL PROTECTED]> escreveu:
From the Schema specification, "dateTime represents a specific instant
of time". Although a timezone-like offset from UTC is allowed in the
representation of a dataTime value, as I understand it this is not part
of the dateTime *value* - in other words, it's just a convenience that
is meant to be stripped away during parsing of the value, just like
leading zeroes on a number. This is implied by both the definition of
dateTime and by the canonical representation, which does not allow an
offset.
I think you read it wrong. UTC are not only allowed and are an integral part of the value, but they should be taken into consideration during canonicalization. Whenever a offset is present, the canonical form _must_ retain that information, i.e., the value must be expressed in UTC by adding the offset and switching to the "Z" form.
You somehow managed to overlook the sentence that immediately preceded this quote: "The class Date represents a specific instant in time, with millisecond precision." Aside from the millisecond reference, this is precisely the same as an xs:dateTime. Your quote just (again) says that java.lang.Date is not intended to be used for formatting and parsing of date strings.The offset part is optional because you can use dateTime to represent local time or time offsets, where timezone offsets are inutile or irrelevant. The JAX-RPC spec has mapped correctly -- Date should never be used when internationalization and UTC are relevant. Quoting the java.util.Date javaDoc:
"Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated. "
I'm having a hard time understanding how people can not see the distinction - a java.lang.Calendar is the mechanism Java supplies for converting between the internal representation of a moment in time (as a long milliseconds value, normally embedded in a Date object) and a text representation in a specific locale. You might want to use a Calendar in the process of converting an xs:dateTime string to a Date value, but the result of the conversion is best represented as an actual Date.
In actual fact, Java does not supply any default conversion that properly handles xs:dateTime. The Schema specification *requires* the use of a proleptic Gregorian calendar, while Java only supplies a mixed Gregorian/Julian calendar with a particular switchover date. Using a java.lang.GregorianCalendar for conversions to and from xs:dateTime values will probably work okay for current values, but will definitely be incorrect if you're working with historical dates.
Yes, it's true - I'm a well-known Microsoft backer. Also, being a U.S. citizen I fully support the gang of thugs currently running this country. :-)Forget about Date. Altogether. Unless you are using JDK 1.0 (i.e. Micro$oft Stagnated Java :-) Hmm. Maybe that is the case, I see you company is in Redmond...
The problem I'm pointing out is that java.lang.Calendar *requires* a choice of time zone and locale. The only choice that would be accurate is UTC with a proleptic Gregorian calendar, which is not a choice that Java provides.Trying to match up a Schema dateTime with a
Calendar is ambiguous at best - for instance, what timezone do you
attach to 2003-10-26T01:15:00-05:00 (which can be either 1:15 am CDT or
1:15 am EST, if I got my math right).
Its "CDT" and "EST" that are ambiguous, not the value. In fact, these acronyms are not mentioned in the standards because they are irrelevant, as is "daylight saving time" (it is called many different names in different countries). Do not confuse offsets with your US "timezones", they are meaningless to everybody else. What realy matters is not how you call the "timezone" -- for example, you can say "Madrid time" or "Paris time" and you still dont know the offset. Say "...T-04:00" and now the time is accurately expressed, and it doesn't matter if it is Summer or Winter, or in which city you are -- maybe it's Tokio.
- Dennis
