I just had a use case where I parse an XML and convert the data to CMIS objects. Of course converting this in my user code is not a big issue, but perhaps this is not such exotic either.
I would assume that most clients want to use their local timezone. I think for other timezones it is okay if the using code has to take for the proper conversion in this case. I am open to other suggestions as well. Jens -----Original Message----- From: Florian Müller [mailto:[email protected]] Sent: Dienstag, 1. November 2011 22:03 To: [email protected] Cc: Jens Hübel Subject: Re: Client API: Make DateTime in convertProperties more tolerant Hi Jens, Supporting XmlGregorianCalendar would not be an issue, but it is not a commonly used data type. Date objects don't have a timezone. In order to support those we would have to decide with timezone to use. GMT or the local timezone of client would be obvious choices. Any suggestions? - Florian On 01/11/2011 12:42, Jens Hübel wrote: > Hi Chemistries, > > > > the client API is pretty tolerant against various data types in a property > map. For example, byte, int, long etc are all accepted for an Integer > property which is a BigInteger in Java. > > > > However for DateTime the converter is very restrictive and just allows > GregorianCalendar. Wouldn't it be more consistent and friendlier if we would > also allow a java.util.Date and an XmlGregorianCalendar here and take care of > the conversion? Furthermore the error message is not very helpful: "Property > 'xyz' is a DateTime property!" doesn't tell you anything about the accepted > type. "Property xyz is of type x but expected is type y" would be much better. > > > > Is there any reason for this I haven't seen? > > > > It also would be helpful for the client developers guide to provide a code > fragment how to set custom properties of the various types. The section > "Advanced use of types" only describes how to read them. The fact that the > Map must not necessarily be a Map<String, String> as in the various examples, > but can also be a Map<String, Object> may not be so obvious for everyone (not > a big deal of course). > > > > Jens > > > >
