commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Tordini <>
Subject Re: [beanutils] java.util.Date converter
Date Mon, 08 Mar 2004 15:12:33 GMT
here's my ISO 8601 converter. It is not really compliant (see javadocs), 
but it can be a starting point.

In my application LocaleConverter is not the solution because I don't 
want date formats to rely on the locale. I read XML files and set 
JavaBeans properties with BeanUtils and I need a fixed international 
dateformat for the users of my app.

I can also make this Converter more configurable, and let the 
constructor accept one or more custom date patterns, this way the user 
can choose the date format, without having to write its own class.


robert burrell donkin wrote:

> On 5 Mar 2004, at 19:06, Craig R. McClanahan wrote:
>> Quoting Flavio Tordini <>:
>>> hi craig,
>>> thank you for your answer. i think the date formats to use are those in
>>>   ISO 8601.
>>> see:
>>> maybe the converter could be added to the beanutils codebase but not
>>> used by default by ConvertUtils. what do you think?
>> That is one of at least twenty different formats for dates and times 
>> that people
>> like to use (and would be pretty user-unfriendly in a locale that likes
>> dd/mm/yyyy formatted dates).  It doesn't seem reasonable to pick just 
>> one, so
>> I'd prefer to let applications that want to use a particular format to 
>> register
>> their own.
> i probably support adding an ISO 8601 compatible convertor to beanutils. 
> ISO 8601 is not only a standard but also one which is commonly used. 
> (i'd thought about creating one before but i became concerned about 
> copyright usage and trademark issues.) adding a convertor based on that 
> w3c NOTE seems very reasonable to me. in addition, the basic date 
> related datatypes used in (w3c flavoured) xml schema is also based on 
> ISO8601 and are similar to those in the NOTE so it would be useful for 
> processing xml documents.
> if the worry is that adding this would establish an unhelpful precedent, 
> then maybe we could add it as an optional class.
> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message