Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-39

Fix for toDate method in DCDate - ID: 2385187



    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.1
    • Fix Version/s: 1.5.2
    • Component/s: None
    • Labels:
    • Attachments:
    • Comments:


      The "toDate" method in org.dspace.content.DCDate (1.4 and 1.5) uses
      GregorianCalendar to convert a DCDate into a Java Date object.

      DCDate convention is to store unknown values (eg, month, day, hours, etc)
      as -1, which is fine for most applications but when setting a
      GregorianCalendar object, it causes dates to roll back incorrectly.

      I first noticed this when it was pointed out to me that in Dspace's RSS 2.0
      feeds, almost all issue dates are displayed as the year previous to the
      actual issue date, on October 30 10:58pm.

      When you see what is happening in "toDate", it is clear:

      > utcGC.set(year, month - 1, day, hours, minutes, seconds);

      Say I have an issue date of "2008". This line will set utcGC to 2008, then
      roll back to November 01 2007 when a month of -2 is referenced, then back
      to October 31 2007 when a day of -1 is referenced. The -1 hour will kick it
      back to 11pm on the 30th, and so on.

      I think there are two good solutions to this.

      The first is to look for alternatives to <pubDate> to use in the RSS feeds.
      It seems to me that a very large majority of issue dates are just a year or
      a month and a year, so forcing a fully formatted date string seems
      (I'm open to the fact that people use dc.date.accessioned in RSS rather
      than dc.date.issued, but dc.date.issued is the Dspace default and I've seen
      it used most often when looking at other repos RSS feeds)

      The second is a small patch to DCDate that will make sure when it is
      converted to a GregorianCalendar object, temporary 'unknowns' of 0s or 1s
      are used instead of -1s, to avoid unwanted rollback:
      This is not a perfect solution by any means, but it means that in
      situations where we only have a year, or a year and a month for a date like
      issue date, but something is trying to display that date as a full Java
      Date object, we'll see more "obvious" defaults like 01 January 00:00, and
      we'll preserve values that are known without rolling them back.

      I have attached the patch (against 1.5 branch) for your review.




            stuartlewis Stuart Lewis
            kipkorir2008 Charles Kiplagat
            0 Vote for this issue
            0 Start watching this issue