Deep dive: Best practices for dates in Islandora MODS metadata

The MODS standard provides a lot of flexibility in recording date values. This is a blessing, because it allows all manner of date metadata to be mapped into MODS and displayed in Islandora. It is also a curse, because highly variable date formats and content cannot be used for consistent date searching, sorting, or faceting.

This document provides best practice guidelines and examples for handling dates in MODS so they will function optimally in LYRASIS-hosted Islandora 7 instances. It will also explain certain limitations and behaviors of this data in Islandora 7.

Please note: the standard MODS entry/editing form that comes by default with all LYRASIS-hosted Islandora instances does not support adding or editing the attribute values described below. If you are interested in bringing your dates into line with these best practices, contact us about enabling the Detailed MODS editing form.

Table of Contents

Best practices


We encourage use of the MODS encoding attribute on date elements where possible.

Islandora 8 aims to support Extended Date/Time Format (EDTF) Level 1 dates out of the box. Because we will eventually migrate all our clients to Islandora 8, we recommend that efforts to standardize date encoding use EDTF.

Unfortunately, Islandora 7 cannot fully utilize EDTF date ranges or qualifications. There are some workarounds shown below demonstrating how you can future proof your dates and achieve the best results now.


Use standard date format where possible:


<dateIssued>March 2019</dateIssued>


<dateIssued encoding="edtf">2019-03</dateIssued>

Prefer EDTF as the standard format, even if the date format meets the criteria for another encoding standard:


<dateIssued encoding="marc">1920</dateIssued>


<dateIssued encoding="edtf">1920</dateIssued>

Avoid coding non-EDTF compliant dates as EDTF:


<dateIssued encoding="edtf">192u</dateIssued>
<dateCreated encoding="edtf">ca. 2004?</dateCreated>

Yes (preferred):

<dateIssued encoding="edtf">192X</dateIssued>
<dateCreated encoding="edtf">2004%</dateCreated>

 or (better than recording wrong encoding):

<dateIssued encoding="marc">192u</dateIssued>
<dateCreated>ca. 2004?</dateCreated>


When multiple dates are recorded, we strongly encourage labeling one of them (and only one of them!) with the keyDate attribute.

Islandora does not currently use this attribute to determine what date value should be used for sorting, but it is on the roadmap.

Ensure that the date tagged as keyDate is in a format that will sort as expected.


Assign a keyDate when multiple dates are recorded:


<dateCreated encoding="edtf">1920</dateCreated>
<dateIssued encoding="edtf">1972</dateIssued>


<dateCreated encoding="edtf" keyDate="yes">1920</dateCreated>
<dateIssued encoding="edtf">1972</dateIssued>


Assign the keyDate to sortable date values, though this may introduce some repetition in the data if you require the textual display:


<dateCreated keyDate="yes" qualifier="approximate">circa 2000</dateCreated>


<dateCreated qualifier="approximate">circa 2000</dateCreated>
<dateCreated encoding="edtf" keyDate="yes" qualifier="approximate">2000~</dateCreated>

Islandora 7 cannot generate "approximately 2000" from the EDTF string "2000~", but it is expected that Islandora 8 will be able to do so.

Assign keyDate to only one date value in a record:


<dateCreated qualifier="approximate">circa 2000</dateCreated>
<dateCreated encoding="edtf" keyDate="yes" qualifier="approximate">2000~</dateCreated>
<dateIssued>2010, 2011, 2013, and 2015</dateIssued>
<dateIssued encoding="edtf" keyDate="yes">2010</dateIssued>


<dateCreated qualifier="approximate">circa 2000</dateCreated>
<dateCreated encoding="edtf" qualifier="approximate">2000~</dateCreated>
<dateIssued>2010, 2011, 2013, and 2015</dateIssued>
<dateIssued encoding="edtf" keyDate="yes">2010</dateIssued>

Note: It would be your choice whether you want this to sort under 2000 (dateCreated) or 2010 (dateIssued).


Islandora 7 cannot currently parse an EDTF interval date into discrete date values that can be sorted or used to populate a facet.

For this reason, we recommend populating additional date elements with point attributes when a date range is assigned.


Explicitly populate date values with start/end point attribute values when specifying a range:

Will not populate date facet:

<dateCreated encoding="edtf">2004-02-01/2005-02-08</dateCreated>

Start and end dates will populate date facet:

<dateCreated encoding="edtf">2004-02-01/2005-02-08</dateCreated>
<dateCreated encoding="edtf" point="start">2004-02-01</dateCreated>
<dateCreated encoding="edtf" point="end">2005-02-08</dateCreated>

Note: for dateIssued elements, only the first-occurring value is displayed. It is on the roadmap to display only non-point dateCreated values, unless there are only dateCreated values with point. In the latter case, a range will be constructed via the pattern "{start value} - {end value}". The other MODS date elements are used less frequently by our clients and are currently all displayed.


It is best practice to populate the qualifier attribute in MODS date elements containing approximate, inferred, or questionable dates. However, this attribute currently has no direct impact on display, search, sorting, or faceting in Islandora 7.

Islandora 8 metadata is not MODS, but given its EDTF support, valid qualified EDTF dates from MODS should migrate properly regardless of whether the qualifier attribute is present.


More details coming soon.



If any dateIssued elements are present, the value of the first-occurring dateIssued is used as the date_sort value.

In the absence of dateIssued values, the value of the first-occurring dateCreated element is used as the date_sort value.

In the absense of either dateIssued or dateCreated, the value of the first-occurring dateOther element is used as the date_sort value.

The current logic does not check for valid date formats, so some strange search result sorting can be explained by "approximately 1992" sorting before "circa 1800".

On roadmap:

Use the first date element value having the keyDate="yes" attribute as the date_sort value.

If no keyDate attribute is set, default to current behavior.


Any MODS date element can be specified as a facet for filtering search results.

The important thing to note here is that you can have a "Date Created" facet and a separate "Date Issued" facet. But there cannot currently be a "Date" facet that combines values from the two different elements.

The labels of facets are easy to change, so you could display the facets as "Creation" and "Publication" or however you wanted to label them.

Note that only values recognized as valid date types by Solr will be included in facets. Range dates and approximate dates as typically recorded for display are not valid date types in Solr, so will not be included in facets, hence some of the apparently redundant data entry recommended above.

There are special options for date facets include a graphical date slider and type-in date range filtering. Example:


If you would like any date facets configured for your Islandora instance, contact us at Zendesk support.


Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk