Commons BeanUtils
  1. Commons BeanUtils
  2. BEANUTILS-255

Date and Calendar Converter implementations

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.0
    • Fix Version/s: 1.8.0
    • Labels:
      None

      Description

      It's impossible to convert a String to a java.util.Date (see commons-user mail thread 'Digester and using of java.util.Date').

        Issue Links

          Activity

          Henri Yandell created issue -
          Hide
          Niall Pemberton added a comment -

          I have a DateConverter and CalendarConverter written - just need to do the test cases

          Show
          Niall Pemberton added a comment - I have a DateConverter and CalendarConverter written - just need to do the test cases
          Hide
          Simon Kitching added a comment -

          I'm not sure this is a good idea.

          Presumably this converter would use the "system locale" to determine how to parse the input strings. This means that
          01/02/2006
          will generate 01 Feb 2006 when run on a server in Europe, and 02 Jan 2006 when run on a server in the USA.

          That's not the kind of behaviour I would like to see a library default to.

          Show
          Simon Kitching added a comment - I'm not sure this is a good idea. Presumably this converter would use the "system locale" to determine how to parse the input strings. This means that 01/02/2006 will generate 01 Feb 2006 when run on a server in Europe, and 02 Jan 2006 when run on a server in the USA. That's not the kind of behaviour I would like to see a library default to.
          Hide
          Henri Yandell added a comment -

          We already have java.sql.Date, Time and Timestamp converters that do that:

          return (Date.valueOf(value.toString()));

          So that's something we're already facing.

          Show
          Henri Yandell added a comment - We already have java.sql.Date, Time and Timestamp converters that do that: return (Date.valueOf(value.toString())); So that's something we're already facing.
          Hide
          Henri Yandell added a comment -

          From David Sillis on the user list

          "Having worked with BeanUtils before, I seem to recall that the main reason there isn't a java.util.Date converter is that unlike java.sql.Date, it doesn't have a favored String format that is guaranteed to convert correctly."

          So that would be the reason why my last comment is wrong.

          Show
          Henri Yandell added a comment - From David Sillis on the user list "Having worked with BeanUtils before, I seem to recall that the main reason there isn't a java.util.Date converter is that unlike java.sql.Date, it doesn't have a favored String format that is guaranteed to convert correctly." So that would be the reason why my last comment is wrong.
          Hide
          Niall Pemberton added a comment -

          The version I have can be configured either to use a specified Locale or an array of patterns. You're right though that it won't cope with different Locales - but thats the purpose of the Locale converters. If someone wants Locale specific conversion they should use that. Also in my mind something is better than nothing and if someone wants nothing they can always "deregister" the date converter anyway.

          Show
          Niall Pemberton added a comment - The version I have can be configured either to use a specified Locale or an array of patterns. You're right though that it won't cope with different Locales - but thats the purpose of the Locale converters. If someone wants Locale specific conversion they should use that. Also in my mind something is better than nothing and if someone wants nothing they can always "deregister" the date converter anyway.
          Niall Pemberton committed 471349 (3 files)
          Reviews: none

          BEANUTILS-255 - add new Converter implementations to support java.util.Date and java.util.Calendar.
          (I have test cases and also plan to switch the existing java.sql.Date/Time/Timestamp Converters to
          use the new generic DateTimeConverter implementation. Holding them back for now to give time for comments)

          Hide
          Niall Pemberton added a comment -

          I've added/updated support for java.util.Date and java.util.Calendar - 99% of the work is in the new DateTimeConverter implementation. I thought I do commit then review, rather than other way round - since its easily reverted in SVN if there are still objections.

          http://svn.apache.org/viewvc?view=rev&revision=471352

          For java.util.Date and java.util.Calendar it can be configured to parse/format dates in one of two ways:

          1) Use the default SHORT date format, either for the default Locale or a specified Locale
          2) Use a set of Date "patterns" with which to try and parse the date

          As Simon pointed out, this isn't going to work for an application that has to deal with multiple Locales - but thats true for all of the "converters" package - and the intention was for peole to use the "locale.converters" package for that scenario. I think providing functionality for "single Locale" scenarios is worth while though.

          Also, its not just about conversion to and from Strings - these also provide conversion between the different date types - which if BeanUtils is copying properties and, for example, the source is a java.util.Calendar and target is java.util.Date - then going via a String, which is what it would do currently is really bad.

          Finally, as I said before people can easily register/de-register converters - so if they don't want the functionality, they don't have to have it.

          Show
          Niall Pemberton added a comment - I've added/updated support for java.util.Date and java.util.Calendar - 99% of the work is in the new DateTimeConverter implementation. I thought I do commit then review, rather than other way round - since its easily reverted in SVN if there are still objections. http://svn.apache.org/viewvc?view=rev&revision=471352 For java.util.Date and java.util.Calendar it can be configured to parse/format dates in one of two ways: 1) Use the default SHORT date format, either for the default Locale or a specified Locale 2) Use a set of Date "patterns" with which to try and parse the date As Simon pointed out, this isn't going to work for an application that has to deal with multiple Locales - but thats true for all of the "converters" package - and the intention was for peole to use the "locale.converters" package for that scenario. I think providing functionality for "single Locale" scenarios is worth while though. Also, its not just about conversion to and from Strings - these also provide conversion between the different date types - which if BeanUtils is copying properties and, for example, the source is a java.util.Calendar and target is java.util.Date - then going via a String, which is what it would do currently is really bad. Finally, as I said before people can easily register/de-register converters - so if they don't want the functionality, they don't have to have it.
          Niall Pemberton made changes -
          Field Original Value New Value
          Link This issue is related to BEANUTILS-179 [ BEANUTILS-179 ]
          Niall Pemberton made changes -
          Component/s ConvertUtils & Converters [ 12311455 ]
          Niall Pemberton made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Assignee Niall Pemberton [ niallp ]
          Niall Pemberton made changes -
          Affects Version/s 1.7.0 [ 12311966 ]
          Issue Type Bug [ 1 ] New Feature [ 2 ]
          Summary ConvertUtilsBean does not support converts to a java.util.Date Date and Calendar Converter implementations
          Henri Yandell made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Niall Pemberton made changes -
          Link This issue is blocked by BEANUTILS-387 [ BEANUTILS-387 ]

            People

            • Assignee:
              Niall Pemberton
              Reporter:
              Henri Yandell
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development