Full Paper

Help or hype?: Standardizing date metadata with AI

  • Annamarie C. Klose 1 ORCID , 
  • Scott Goldstein 2 ORCID
  • 1 The Ohio State University, US
  • 2 McGill University, CA
Available
DOI
https://doi.org/10.23106/dcmi.952641480
Access and licence
Open access CC BY 4.0
Download PDF
Contents

Abstract

There is a wide variety of date metadata practices employed by professional, paraprofessional, and volunteer catalogers and metadata creators. The lack of standardization in date metadata inhibits discovery. While normalization routines can be created to improve metadata, the sheer scale of date values and types of date formats can make that time consuming and onerous. As artificial intelligence (AI) is employed in metadata work, this paper addresses its potential usefulness in standardizing date metadata in more frequently used scenarios. In this exploratory study, the researchers employed several freely available AI chatbots: ChatGPT, Claude Sonnet, and Gemini.

1 Introduction

Metadata cannot be interoperable without consistency. Research points to differing standards and practices with date metadata that can inhibit discovery of records.[1–3] An example is the Digital Public Library of America (DPLA), an aggregator of more than 50 million digital cultural heritage records from institutions across the United States, which has date values in thousands of different formats. While normalization workflows can be created for standard date patterns, mass reformatting of date values can be time-consuming and unwieldy. This paper discusses exploratory work that delves into the potential of artificial intelligence (AI) to standardize date metadata. While there are various date standards across the globe, the experiments focused on the Library of Congress' Extended Date/Time Format (EDTF), a profile of ISO 8601. The latter is the international standard for date and time metadata.

2 Methodology

To provide samples of common date metadata values, a data set was extracted from the Digital Public Library of America (DPLA). The March 2025 snapshot of the DPLA data set was downloaded as zipped JSON files from their public Amazon Simple Storage bucket. Based on previous experience working with DPLA data sets, all records were preemptively de-duplicated on the ID field. Next, all display date values were extracted and processed through a function that “abstracted” common date-specific features and replaced them with a simple generic string. In particular, full month names were replaced with the string “Month”, abbreviated month names were replaced with the string “Mon”, and all numerals were replaced with the string “9”. As an example, a date value of “February 16, 2026” would be transformed into “Month 9, 9999” after passing through this function. The purpose of this step was to organize dates into patterns that could then be tabulated and sorted based on how frequently they appear in the data set. Finally, random samples were drawn from the 100 most commonly used date patterns. The output constituted a mixture of natural language, encoded dates, and values that had both natural language and encoding. All data preprocessing was done using R in an advanced research computing cluster; for more information, see Klose, Goldstein, and Levy[3].

Four freely available AI chatbot models—ChatGPT 4.1, Claude Sonnet 4.6, Gemini 3 Flash, and Gemini 3 Pro—were tested from a location in the United States at erratic intervals, first with a random example from each of the first fifty date patterns and later a random example from each of the next fifty date patterns, for a total of 100 date values. Utilizing a framework from Radio, White, and Eichmann-Kalwara[4], the researchers employed confidence levels to assess each chatbot's evaluation of its own output. They began with a role-based prompt: “You are an expert library cataloger. Validate these dates according to the Extended Date Time Format. Output in a column. Add a column with your confidence in this work based on a scale of 1 to 5.” As needed, additional prompts were given to finetune the output and export the results to a spreadsheet. The complete set of exchanges between the researcher and the chatbots were also copied and pasted into a document to retain all the chatbots' notes. The data sets were merged into a master spreadsheet1 to compare the results from each chatbot. When ChatGPT 5.3 and Gemini 3.1 Pro were released, additional tests were conducted. The date samples were identified in a master spreadsheet with their date pattern's ranking (i.e., frequency in the DPLA), a manual conversion to EDTF, the example's EDTF validity and level, and related notes. For comparison, the researchers used the University of North Texas' (UNT) edtf-validate code[5] with the data set and incorporated its results into the master spreadsheet. The researchers' manual validity assessment and UNT code concurred on the EDTF validity of fifteen date strings in the original data set as well as the remaining eighty-five strings being invalid. As some chatbots put notes in the normalized date values, a standardized version of the master spreadsheet was created to provide only structured information for further analysis. When necessary, the researchers referred to source records corresponding to the date pattern for more context.

3 Results

ChatGPT, Claude, and Gemini had similar results and understanding of EDTF for more rudimentary date conversions. As testing was done in the United States, the chatbots recognized the typical American encoding standards. In more complicated cases, they had drastically different results and interpretations. In addition, ChatGPT typically needed more prompting, e.g., asking for results in a table format or adding a column for EDTF levels. Although the 5.3 model represented a significant improvement over the 4.1 model in this respect, it gave two different responses in one test for the same prompt. That could pose a challenge for novice metadata creators. Claude and Gemini were more user-friendly and returned results that were in a table format with explanations, necessitating fewer prompts for the desired output. Gemini Pro and Gemini Flash sometimes had subtle differences in their responses. The various chatbot models sometimes changed their approach when tests were repeated over time.

3.1 Comprehending the rules

The chatbots seemed to understand that there is a relationship between EDTF and ISO 8601. Although the models were proficient with Level 0, they had some issues with Levels 1 and 2. They would get wrong about how and why. Their knowledge related to the library content standards Resource Description & Access (RDA) and the Anglo-American Cataloguing Rules, Second Edition, (AACR2) varied.

3.1.1 "Undated" and "unknown" dates

EDTF is opaque on how to address unknown dates. Although character X is used for unspecified digits, it does not indicate whether one can use that for all digits in a year. In some cases, humans have interpreted this as XXXX. In cataloging, the string "uuuu" can be used to express an undated work. The letter "u" as an unspecified date character was a precursor to the character "X" in the EDTF specification.[6] According to ISO 8601-2: 2019, section 9.2.1.2, the string "XXXX" indicates a "a calendar date with year precision, where the year number is unspecified but with four digits" in the implicit form[7]. Consequently, the appropriate value for a work with no date could be either "XXXX" or no value. Similarly, ChatGPT, Claude Sonnet, and Gemini had different approaches to natural language values that indicated unknown, no date, undated, and related abbreviated terms with a high level of confidence. ChatGPT 4.1 and 5.3 returned the value "unknown" while Claude Sonnet 4.6 and Gemini 3 Flash normalized to "XXXX". (An earlier test of test of Gemini Flash resulted in "uuuu".) Gemini 3.1 indicated to "(Omit from metadata)".

3.1.2 Level 0

ChatGPT, Claude, and Gemini were all able to recognize date values that complied with EDTF Level 0 and how to apply its rules to standardizing date values. This means dates with complete representation (YYYY-MM-DD), reduced precision for year and month (YYYY-MM), reduced precision for year (YYYY), and complete representations for calendar dates with the time of day, including Coordinated Universal Time (UTC). These also overlap with the W3C Date and Time Formats (W3CDTF)[8]. All recognized typical natural language dates in English with ease regardless of the order of the components in the strings. Examples include: DD Month YYYY; Month YYYY; and Month DD, YYYY. There were no issues with converting dates where months were abbreviated to three letters, e.g., DD Mon YYYY and D Mon YYYY. All tools completed the conversions accurately with a confidence rating of 5.

The chatbots also had no problem recognizing and converting values in terms of date ranges with start and end dates. These are referred to as intervals in EDTF, with the most basic version in Level 0 lacking qualifiers, e.g., YYYY/YYYY, YYYY-MM/YYYY-MM, and YYYY-MM-DD/YYYY-MM-DD. ChatGPT, Claude, and Gemini demonstrated proficiency with recognizing Level 0 intervals values and converting natural language date ranges to them with a confidence of 5. Examples are: "1854 to 1855" normalized to "1854/1855"; "Jan 1903 to Feb 1903" normalized to "1903-01/1903-02"; and "8 Aug 1938 to 19 Aug 1938" converted to "1938-08-08/1938-08-19".

3.1.3 Level 1

In many scenarios, the chatbots transformed the date values according to Level 1 sufficiently. However, some models had challenges with normalizing natural language values related to decades and centuries. For the value "1850s", Claude Sonnet 4.6, Gemini 3 Flash, and Gemini 3.1 Pro all normalized it correctly to "185X" with a confidence of 5. ChatGPT 4.1 also had this conversion but with a confidence of 4. However, Gemini 3 Pro offered two options: “185X (2012 spec) or 185 (2019 ISO standard)”. While the first option is the correct transformation for a Level 1 unspecified digit, it reflects the 2019 standard—not the 2012 draft. In addition, the draft standard has an “u” rather than an “X” for the unspecified digit. Therefore, the second option is erroneous. The Differences section of the EDTF webpage clearly notes the change and the “u” also reflects longstanding cataloging practice. Despite this misstep, the model had a confidence of 5. Natural language in terms of centuries was easy for most of the chatbots to interpret and standardize with high levels of confidence. ChatGPT 5.3, Claude Sonnet 4.6, and Gemini 3 Flash correctly normalized "17th century" as "16XX". The outlier was Gemini 3.1 Pro which indicated "16 (or 16XX)" as its result. All models had a confidence of 5 for this task. While the value could also be normalized as "1600/1699", the "16" value is not valid in EDTF.

3.1.4 Level 2

Set representation values presented a challenge. With a confidence of 5, Claude Sonnet and both Gemini models identified existing set values as valid per Level 2 and left them intact. The Gemini models were correct when referring to these as one of a set. However, Claude fumbled the terminology referring to one value as an “inclusive date range” and the other as an “inclusive interval”. Intervals are a concept in Level 0 that is applied differently in Levels 1 and 2. However, the wording in the Differences section of the EDTF webpage for the string “..” requires close reading to understand its application for intervals rather than set representation as the string “..” is also employed in set representation. On the other hand, ChatGPT erroneously converted set representation values to Level 0 date ranges, e.g. “2011-06-24/2011-06-25”, with a confidence rating of 4. In terms of converting date values for set representation, the chatbots had different approaches and confidence levels (Table 1). Claude Sonnet 4.6 and Gemini 3.1 Pro normalized the value "1697; 1830" as a set with a high-level of confidence. ChatGPT 5.3 and Gemini Flash 3, however, converted the value in ways that are not EDTF valid.

Table 1. Level 2 date with the value "1697; 1830"
ModelNormalized valueConfidence
ChatGPT 5.3a1697,18303
Claude Sonnet 4.6{1697,1830}4
Gemini 3 Flash[1697, 1830]4
Gemini 3.1 Pro{1697, 1830}5

a This example was not tested with ChatGPT 4.1.

3.2 Interpreting characters

An enlightening aspect of the testing was seeing how the chatbots recognized common characters in date values.

3.2.1 Hyphens

Typically, hyphens are used in date ranges in the United States. But they have a different meaning in ISO 8601, WCDTF, and EDTF as separators between year, month, and day, e.g. YYYY-MM-DD. In addition to the aforementioned tests, the chatbots recognized the inherent differences between a hyphen used to separate a date range, e.g. “YYYY - YYYY”, and as a separator between units of year, month, and day, e.g. YYYY-MM-DD. With high confidence, all chatbots converted the value “1890 - 1930” to “1890/1930” per Level 0. In addition, the value “1958-04-04-1959-03-27” awkwardly included a hyphen to denote a date range and as a separator between year, month, and day. ChatGPT, Claude, and Gemini successfully converted the value to “1958-04-04/1959-03-27”. Oddly, ChatGPT 5.3 had confidence scores of 5 and 4 for the two different response options despite the same results for this example. Both Gemini models had a confidence of 5; Claude had a confidence of 4.

3.2.2 Square brackets

In library content standards, square brackets are used to signify inferred dates, but the chatbots had mixed responses to them. The Concise AACR2: Based on AACR2 2002 Revision, 2004 Update (AACR2), section 0A, indicates to use square brackets for information “from outside the bibliographic resource or have composed it yourself"[9]. Both ChatGPT and Gemini Flash generally understood this concept, removing the brackets when normalizing date values, e.g., “[1738]”, with a fairly high level of confidence. With a confidence of 3, ChatGPT 4.1 normalized to "1738 (remove brackets)". ChatGPT 5.3 simply removed the brackets with a confidence of 4. Gemini 3 Pro and 3.1 Pro each provided two options, converting the value to "1738 or 1738?" and "1738? or 1738~", respectively, with a confidence of 5 for both. However, Claude left the square bracket set intact when reformatting this value. As square brackets are used in EDTF only for set representation, e.g. [2011-06-24..2011-06-25], this was an EDTF conversion failure. In other cases, Claude Sonnet continued to maintain or add brackets where they were unnecessary and invalid according to EDTF.

3.3 Ambiguity & bias

A challenge in converting dates to another format is ambiguity. The chatbots had varying responses to ambiguous dates. They demonstrated biased assumptions that may or may not be accurate when reformatting date values.

3.3.2 Two-digit years

In cases where a year was only indicated by its last two digits, the chatbots demonstrated a bias towards converting values to 20th century dates. For the value “Transcribed d/m/y: 4/6/35”, all chatbots converted the date to “1935-06-04”. However, they had varying levels of confidence with Gemini 3 and 3.1 Pro at 5, Gemini 3 Flash at 4, Claude Sonnet 4.6 at 3, ChatGPT 4.1 at 2, and ChatGPT 5.3 at 2 and 3 for its two responses. Several chatbots referred to the ambiguity and assumptions made in the responses' notes.

3.3.3 Ambiguous ordering of month and day

The chatbots also recognized the ambiguity of dates where the order of month and day was not obvious. The MM/DD/YYYY format is typically used in the United States. However, applying US standards to the DPLA values may or may not be correct depending on the context. However, the chatbots had medium to high confidence in these tasks (see (Table 3). In one example, all models except ChatGPT 5.3 provided notes on their reasoning for one or more of their results. In the case of “10/05/2007”, ChatGPT changed its speculation from one model to the other. ChatGPT 4.1 presumed the value matched the DD/MM/YYYY format; version 5.3 assumed the MM/DD/YYYYY format.

Table 3. Date value "10/05/2007" with ambiguous ordering of month and day
ModelNormalized ValueConfidence
ChatGPT 4.12007-05-103
ChatGPT 5.32007-10-053
Claude Sonnet 4.62007-10-05 or 2007-05-103
Gemini 3 Flash2007-10-054
Gemini 3 Pro2007-05-10 or 2007-10-055
Gemini 3.1 Pro2007-10-05 (or 05-10)5

3.4 Extrapolating information

There are cases where an educated guess is suitable. One may easily infer that “3/15/2016” and “1915/05/30” can be interpreted as M/DD/YYYY and YYYY/MM/DD, respectively, based on the number of digits to encode months and days. ChatGPT, Claude, and Gemini were all able to successfully make this assumption and convert the values to “2016-03-15” and “1915-05-30”, respectively, with medium to high confidence. ChatGPT 4.1 and Claude Sonnet provided useful context regarding the assumptions in their notes.

As noted previously, there were date values with explanatory text strings, e.g., “Transcribed d/m/y:”, preceding an encoded date value, e.g., “Transcribed d/m/y: 10/5/36”. In those cases, all chatbots were able to extrapolate the context regarding the ordering of day, month, and year to normalize the date as "1936-05-10" while assuming the century. As this normalization task involved both extrapolation and deducing the century, confidence levels varied: ChatGPT 4.1 had a 2; ChatGPT 5.3 and Gemini 3 Flash had a 3; Claude Sonnet 4.6 had a 4; and Gemini 3 and 3.1 Pro had a 5. In earlier tests, Claude Sonnet 4.6 only had a confidence of 3 and Gemini Flash 3 had a confidence of 4. Notes from many of the chatbots confirmed that they were able to reason the day/month/year ordering from the prefix text string of d/m/y. Consequently, these tasks were successful in terms of extrapolating information.

3.5 Malformed dates

Date values to standardize may also include errors. Sometimes the chatbots could identify and remove stray characters during normalization. For instance, all chatbots converted the value "1779." to "1779" recognizing that the period was unnecessary. However, the chatbots had different approaches to other errors. There were date values with a closing square bracket—"1852]" and "1819?]"—but no opening bracket. The source of this issue appears to be a mapping issue from harvested MARC records. All the chatbots understood dates with one square bracket to be problematic. In both cases, ChatGPT 4.1 and 5.3, Gemini 3 Flash, and Gemini 3.1 Pro removed the single square bracket, leading to a set of EDTF valid results. Both Gemini models had high confidence in these tasks, while ChatGPT models had low to high confidence. However, Gemini 3 Pro outperformed its later version, 3.1 Pro, with the output "1852" over the erroneous "1852?". The outlier was Claude Sonnet 4.6. In the first test, it added an opening bracket to both values with a confidence of 4. In a later test, it did not normalize the values, noting that the original values were "malformed", with a confidence of 1.

There were also the puzzling examples of "18" and "299" from DPLA hubs including the Smithsonian Institution and HathiTrust. Upon examination of the original records, it became clear that a simple normalization routine would be unsuitable for these date patterns. Some Smithsonian Institution records contained a Collection Date of two or three digits. A HathiTrust MARC record for a 19th century serial had the value "18--" in the 260 $c but the hyphens did not exist in the harvested metadata in DPLA. The value "18" led to inconsistent results from the chatbots, including both Gemini models (see Table 4). For the "299" value, all chatbots normalized it to "0299". Assorted confidence values were: Gemini 3.1 Pro and Gemini 3 Flash at 5, Claude Sonnet 4.6 at 4, and ChatGPT 5.3 at 2. These two examples were not tested with the older models of Gemini Pro and ChatGPT. Unfortunately, the records in these date patterns require granular review by a human.

Table 4. Malformed date "18" with missing digits
ModelNormalized valueConfidence
ChatGPT 5.318XX2
Claude Sonnet 4.618XX4
Gemini 3 Flash183
Gemini 3.1 ProN/A4

3.6 Accuracy and confidence ratings

Table 5 summarizes each model's accuracy and confidence ratings. In calculating these metrics, the researchers excluded eight values from the data set that were ambiguous or lacked enough context to make an informed judgment. In cases where more than one normalized value is acceptable, it was considered accurate if the model gave any one of the researchers' possible normalized values. In spite of the aforementioned differences around handling edge cases, the four models performed comparably well, with each having an accuracy percentage in the low to mid-80s. Self-assessed confidence ratings were deceptive; they did not correlate with whether the results were accurate or not.

Table 5. Accuracies and confidence levels across the models
ModelAccuracy (%)Mean overall confidenceMean confidence for correct valueMean confidence for incorrect value
ChatGPT 5.382.614.654.724.31
Claude Sonnet 4.681.524.604.763.88
Gemini 3 Flash83.74.834.844.73
Gemini 3.1 Pro85.874.984.994.92

4 Limitations

There are several limitations to this study. The tests were conducted at erratic intervals by a single user in one location rather than frequent intervals by multiple users in dispersed global locations. The models' output may be affected by the limited scenario used in these tests and likely the geographic location. In addition, the context of some sample date values was unclear without referring to the original record. Only the institutions or, more specifically, the individuals who created those values can understand the full context and whether the values contain errors or are intentional. Some of the date patterns represented mapping issues during the harvesting process that obscured the date context in the original record. Whether a record represented a serial or an individual item also affected the context. Another complication is that some standards, such as RDA and ISO 8601, exist behind a paywall. Due to the role-based prompt for a cataloger, access to RDA and AACR2 would play a role in interpreting the date examples. Without transparency about the resources chatbots are exposed to, one cannot know if they have reliable and accurate information. In addition, AI can be prone to concept drift in scenarios where information is constantly being changed[12].

5 Conclusion

AI has advanced to a point where it can assist with normalizing some date metadata according to formats such as EDTF. However, it still faces reliability challenges and requires training to improve outcomes. By testing several free AI chatbot models, it is clear that each had advantages and disadvantages in recognizing the EDTF rules and standardizing the values. While Gemini 3.1 Pro had a slight edge, no model significantly outperformed the others in all use cases. The newer models did not always perform better.

Natural language is not a barrier to using AI to standardize date values. However, the chatbots sometimes handled ambiguous dates and characters, e.g., square brackets, in ways that were not optimal. In addition, the chatbots' perception of their reliability and the accuracy of their results were often contrary to the reality. Reasoning capabilities varied, including the comprehension of library content standards for dates. However, they were able to reason that a text string of "d/m/y" before an encoded date had meaning and could extrapolate its meaning.

Although EDTF supports machine-readable dates, its complicated documentation to create those dates has gaps and is often challenging for a human to comprehend—much less a machine. The EDTF documentation should be more user-friendly as well as machine readable. In addition, the chatbots were sometimes confused by how other content standards, e.g., AACR2, overlapped—or did not—with EDTF. These chatbots are constantly evolving and may improve over time. Currently, they are useful for standardizing date metadata in the most common date metadata scenarios and those that lack ambiguity. Despite their benefits, AI chatbots have flaws in terms of normalizing more complex date scenarios.

Lastly, the example records in the first one-hundred DPLA date patterns represented a variety of description practices and errors. Even when the researchers and chatbots converted the example values, reviewing the source records often led to a more nuanced understanding of the content and how its date value should be normalized. In many cases, a standard transformation from a third party without the necessary context led to errors. At an institutional level, these considerations with the chatbots' normalization routines could be minimized where description practices are consistent and well-documented. In such cases, chatbots could be trained for this work. Nevertheless, erroneous conversions of date metadata could impair patrons' understanding of the resources described. As with all AI-generated content, human-in-the-loop review is highly advised.

Acknowledgments

Special thanks to Masha Stepanova and Rocki Strader for providing cataloger insights on the DPLA examples and EDTF interpretations.

References

  1. [1] R. Tennant, Digital Libraries: Metadata's Bitter Harvest. in Library Journal, vol. 129, no. 12, 2010.
  2. [2] S. L. Shreeves, J. Riley, and L. Milewicz, Moving towards shareable metadata. in First Monday, vol. 11, no. 8, 2006. https://doi.org/10.5210/fm.v11i8.1386.
  3. [3] A. C. Klose, S. Goldstein, and M. S. Levy, It's About Time: Use of The Extended Date/Time Format in the Digital Public Library of America. in Library Resources & Technical Services, vol. 69, no. 4, 2025. https://doi.org/10.5860/lrts.69n4.8549.
  4. [4] E. Radio, P. White, and N. Eichmann-Kalwara, Measuring and Critiquing genAI tools for Geographic Metadata Creation. 2025. https://docs.google.com/presentation/d/10ikTB8E6xi8mXeWM4iARZcBmLfPTLcmhTOlmbO-FlEA/edit.
  5. [5] University of North Texas Libraries, edtf-validate. in GitHub, 2021. https://github.com/unt-libraries/edtf-validate.
  6. [6] Library of Congress, Extended Date/Time Format (EDTF) Specification. 2019. https://www.loc.gov/standards/datetime/.
  7. [7] ISO, ISO 8601-2: Date and time — Representations for information interchange — Part 2: Extensions. ISO, pp. 36-38, 2019.
  8. [8] W3 Consortium, Date and Time Formats. 1997. https://www.w3.org/TR/NOTE-datetime.
  9. [9] M. Gorman, The concise AACR2: based on AACR2 2002 revision, 2004 update. [object Object], pp. 11, 2004.
  10. [10] M. Gorman, The concise AACR2: based on AACR2 2002 revision, 2004 update. [object Object], pp. 33, 2004.
  11. [11] G. de Groat, Future directions in metadata remediation for metadata aggregators. Digital Library Federation, pp. 18, 2009. https://old.diglib.org/aquifer/dlf110.pdf.
  12. [12] K. S. Desale, Concept Drift in Large Language Models: Adapting the Conversation. [object Object], pp. 7, 2025. https://doi.org/10.1201/9781003595533.

Notes

  1. 1. The data set can be found in The Ohio State University's Knowledge Bank: https://kb.osu.edu/handle/1811/107249 ↩

Article details

Available
Section
Full Papers
DOI
10.23106/dcmi.952641480
License
CC BY 4.0 · open access
Download
Download PDF

Described in Dublin Core

This article's metadata, in the vocabulary these proceedings are about.

dcterms:title
Help or hype?: Standardizing date metadata with AI
dcterms:creator
Klose, Annamarie C.
Goldstein, Scott
dcterms:available
2026-08-01
dcterms:identifier
doi:10.23106/dcmi.952641480
dcterms:publisher
Dublin Core Metadata Initiative
dcterms:type
Text
dcterms:language
en
dcterms:rights
CC BY 4.0
Harvest this record via OAI-PMH →