"Choose year" dropdown for Browsing by Issue Date can fail to show all years from the results

[uofmsean]

Describe the bug DSpace 7.6.1, Firefox 122, Chrome 121.0.6167.85

If the dc.date.issued metadata for an item has an invalid date format with a two-digit year (e.g., 22-01-01 instead of 2022-01-01) this can cause the Browse by Issue Date's "Choose year" dropdown to only show the current year.

This is due to the splitting up of the date ranges, and, in the example, a year of 22 causes all decades from 20 on up to 1990 to be added to the dropdown. In Firefox and Chrome, the dropdown was only showing the current year of 2024, whereas Safari 17.2.1 would show all the date ranges (20-1990 in decades, 1995, 2000, 2005, and then each year from 2010 to 2024).

To Reproduce Steps to reproduce the behavior:

1. Modify an item's dc.date.issued to be something like 22-01-01 where the year is two digits
2. The change should cause an update to the search index (wait a minute to be sure), or, if necessary, initiate a full dspace index-discovery -b rebuild
3. Go to Browse by Issue Date for All of DSpace
4. Check the "Choose year" dropdown in Firefox or Chrome, and it will only show the current year

Expected behavior Although it was due to bad data in our case, it would have been preferred that the dropdown in Firefox and Chrome showed the long list of date ranges as Safari did. At least in that case, it would have highlighted that there was a bad date in the metadata regardless of the browser chosen. If there are limits to how many items could reasonably be shown in some browsers, then the logic that generates the list of years to choose from should be extended to more efficiently reflect the years present in the current browse results.

Related work This was once reported for the DSpace demo site and could be related. See DSpace/DSpace#9062

[alanorth]

@uofmsean yes you are right, we have since run into this as well. I didn't understand the original bug and dismissed it.

In one community where this was happening, I exported the community as a CSV and found issue dates in format:

• YYYY-MM-DD — Good!
• MM/DD/YYYY — Bad!
• Blank — Bad!

One solution is to fix the invalid dates. Is there something we can do in the frontend to handle this, or is this a backend issue?

[mwoodiupui]

The back-end should protect itself against invalid dates, regardless of what the front-end is doing. It would be nice if we had actual metadata schemas, which could tell the code that this field is a date so it can be normalized as such. Short of that, I guess the metadatavalue service will need to check for fields that are supposed to be dates and special-case them.

OTOH front-ends should send valid dates regardless of what the back-end is doing with them.

So: it should be fixed in both places.