Hi, I know that this is on the Todo list, but as I need the ability to deal with UTC offsets now, I thought I may try and do it myself. First I'd like to make sure I've got the right end of the stick as far as legal representations of datetime go. As I understand it the following are legal for xs:datetime: CCYY-MM-DDThh:mm:ss CCYY-MM-DDThh:mm:ss.SSS CCYY-MM-DDThh:mm:ssZ CCYY-MM-DDThh:mm:ss.SSSZ CCYY-MM-DDThh:mm:ss+/-hh:mm CCYY-MM-DDThh:mm:ss.SSS+/-hh:mm what wasn't so clear from the schema spec was whether CCYY-MM-DDThh:mm:ssZ+/-hh:mm CCYY-MM-DDThh:mm:ss.SSSZ+/-hh:mm were valid. The text seem to imply it was... As far as parsing the dates go, I would appreciate some worldy advice :-) Sun JDK 1.3's SimpleDateFormat has some thoroughly undocumented support for parsing numerical UTC offsets of the form +/-hh:mm, but I have no idea whether this is generally the case in previous Sun JDK's, or in the IBM JDK etc. Does anyone know? I supposse, if it's undocumented the safeest thing would be to assume that its not there, and read in the UTC offset (if present) 'by hand'. As for formatting the dates, it seems that there's two parts that are optional, i.e. the inclusion of the millieconds and the inclusion of the 'Z' token to indicate UTC. In my case, at least, the milliseconds are undesireable as I can't gurrantee that third parties parsing the XML will be able to cope. Would it be reasonable to make the inclusion or otherwise of each of these controlable in the castor properties? Finally, would it be most desireable to just extend the code as it stands in DateFieldHandler, or to try and implement some kind of XmlSchemaDateTimeFormat (catchy name, eh?) that extends DateFormat? Cheers Owen -- Owen Green Software Developer, Unique Interactive 50 Lisson St, London, NW1 5DF [EMAIL PROTECTED] http://www.uniqueinteractive.co.uk ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
