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.