fix: make seasonal EDTF dates display properly in item metadata

[Aryan-R-Patel]

GitHub Issue: #153

What does this Pull Request do?

This PR fixes the bug where EDTF seasonal codes (21-41) were displayed as raw numeric values (e.g. 1981-21) in the item metadata. It ensures that these codes are now translated into human-readable strings (e.g. Spring 1981 for 1981-21) as per the EDTF standards.

What's new?

• Modified EDTFFormatter.php (formatDate() method) to detect seasonal codes and map numeric codes to their respective names via MONTHS_MAP from EDTFUtils.php.
• Updated the display to always display a "Month [space] Year" format for better readability.
• Does this change require documentation to be updated?
  No (this is only a display fix since we already have support for EDTF)
• Does this change add any new dependencies?
  No
• Does this change require any other modifications to be made to the repository
  (i.e. Regeneration activity, etc.)?
  No
• Could this change impact execution of existing code?
  No (it only changes how the seasonal dates are displayed)

How should this be tested?

1. Reproduce the issue: On an islandora site, edit any item and enter a seasonal date such as 1981-21 into an EDTF date field. If you view the item, it will display 1981-21 (raw month code)
2. Apply this PR
3. Test with changes:

• Go to the same item (as in Step 1), and now it should display Spring 1981.
• Test with edge cases as well. For example, 1981-23? should display Autumn 1981 (year and month uncertain).

Additional Notes:

The PR forces a "Month [space] Year" order for because it makes more sense to use it over standard "Big-endian" formatting (Year-Month) (i.e., Spring 1981 is preferred over 1981 Spring).

[PurveshMali]

Thanks for reporting this.
I’ve reviewed PR #154 and tested the fix locally.
I’ll follow up if I notice any edge cases or required improvements.

[Aryan-R-Patel]

Sounds good!

[joshdentremont]

I just commented on the issue with how I handle this on my site (#153).

I don't know if we want to hard code it in this way because then there is no way to display it as numbers.

If we wanted to give users the option to have 2 digits for months but spelled out for seasons, like in your example, maybe it would be better to add a new month format option that allowed for that, but left the existing ones as is.

[joshdentremont]

We just talked about it on the tech call and we don't want to merge this as is because we don't want to change the behaviour of the existing month formatter.

We discussed two different options that could fix this for you:

1. You could override the formatter in your own local code and make this change in your own custom module
2. You could add a new month formatting option that displays numbers 1-12 as numbers but 21+ written out. So basically exactly what you have done here, but as another option in the month formatter, instead of changing the existing one.

[Aryan-R-Patel]

Thanks for the follow up.

I will definitely try to add a new month formatting option that preserves the current numeric behaviour for months 1–12 while rendering seasonal codes (21+) as human-readable, and leave existing formatters unchanged.

I will follow up with an updated PR after I have completed the new approach.