George,
I would say that it could be more gracefully handled in the UI so that there
are not parsing errors. But, the larger challenge is that its not a problem
with the UI, the expectation is that the dates are ISO format, putting other
values into that field is invalid. If anything were to be fixed, the fields
should be properly typed and validated on submission / item edit / import to
stop such values getting into there in the first place.
I would recommend starting a JIRA task (if one does not already exist) about
the topic if its something that you would like to see fixed in the future.
Mark
On Thu, Aug 18, 2011 at 11:48 AM, George S Kozak <[email protected]> wrote:
> Hi, Susan:
>
> I reported the same problem back in May. I was told to exported the
> metadata for the problem records and then reimport them after fixing them.
> That worked, but I never heard anyone saying that the problem was going to
> be fixed.
>
> George Kozak
> Digital Library Specialist
> Cornell University Library Information Technologies (CULIT)
> 501 Olin Library
> Cornell University
> Ithaca, NY 14853
> 607-255-8924
> ________________________________________
> From: Thornton, Susan M. (LARC-B702)[LITES] [[email protected]]
> Sent: Thursday, August 18, 2011 12:13 PM
> To: [email protected]
> Subject: [Dspace-tech] Bad date problem in DSpace 1.7.1
>
> Hi,
> I am in the process of upgrading from DSpace 1.5.1 to 1.7.1. I am
> almost done and am running index-init, but I’ve just noticed a problem.
> With previous versions of DSpace, if a “bad” date was encountered in one of
> the date fields (issue date, accession date, publication date), DSpace just
> ignored it. Now, it seems it is unable to either display the Item page or
> the Browse screen if encounters one of these records. Here’s an example:
>
> One of our items has the following invalid issue and publication date that
> our Users have never gotten around to correcting:
>
> "Washington, D.C. :1955."
>
> If I try to display the Item, the screen is blank and the following message
> displays in the dspace.log file:
>
> 2011-08-18 12:07:14,232 WARN org.dspace.content.DCDate @ Mangled date:
> Washington, D.C. :1955. ..failed all attempts to parse as date.
>
>
> The same message displays if I try to browse by issue date.
>
> I know the “right” thing to do is to clean up our data, but I also know we
> have quite a few of these old bad dates and am wondering why DSpace is now
> having a problem with it.
>
> Thanks,
> Sue
>
>
>
> Sue Walker-Thornton
> Software Developer/Database Administrator
> NASA Langley Research Center|LITES Contract
> SGT, Inc.|130 Research Drive
> Hampton, Va. 23666
> Office: (757) 224-4074
> Mobile: (757) 506-9903
> Fax: (757) 224-4001
> [email protected]
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> DSpace-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
