>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. 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. " 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... >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. Again, stick to the JAX-RPC mapping. It is correct, and the safest way to go. ============================================= Marcelo Jaccoud Amaral mailto:jaccoud [at] petrobras.com.br ============================================= There are only 10 kinds of people in the world: those who understand binary and those who don't. Para: [EMAIL PROTECTED] 02/06/2003 19:17 cc: Favor responder a Assunto: Re: sample code: using java.util.Date instead of axis-user java.util.Calendar 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. That makes the (non-deprecated) java.util.Date the closest match to a dateTime. The problem is that people keep trying to add timezone information (even though it's not supported by Schema), which is apparently why the JAX-RPC spec requires using Calendar instead. Calendar is specifically "for converting between a Date object and a set of integer fields such as YEAR, MONTH, DAY, HOUR, and so on", and requires a specific time zone and associated set of conversion rules in order to be meaningful. 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). I think this really is an error in the JAX-RPC spec, though I doubt they'll be willing to make a change. You know Schema better than I do, Stu - what do you think? - Dennis Dennis M. Sosnoski Enterprise Java, XML, and Web Services Support http://www.sosnoski.com Redmond, WA 425.885.7197 Stu Halloway (DevelopMentor) wrote: >Hi, > >In response to "ow"s request for java.util.Date <-> xsd:dateTime >conversion, I have written an Axis sample that uses a custom generator >in WSDL2Java to bind dateTime to java.util.Date instead of >java.util.Calendar. You can download the sample set at [1], the sample >is called StaffLocator. > >Note: I am not endorsing (or condemning) this approach and I understand >that this mapping is contra the JAX-RPC spec. It's just a sample. :-) > >Please let me know if there are better approaches or if there are other >samples you would like to see. > >Stu > >[1] http://staff.develop.com/halloway/wsdlAndAxis/axisSamples.zip > >Stuart Halloway >DevelopMentor >Guerrilla Java Web Services June 16! >http://www.develop.com/courses/gjws > > > >
