Patches item #2385187, was opened at 2008-12-03 23:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=319984&aid=2385187&group_id=19984
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kim Shepherd (kshepherd) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for toDate method in DCDate Initial Comment: 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 strange. (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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=319984&aid=2385187&group_id=19984 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
