Do not set humanized date when not set

[PascalLike]

Humanized date is showed also when the setting is not set:

And is not possible to see the time in the date without checking the XML.

This change was suggested by @wangf1122 in this issue #8409.

This PR does the following changes:

• When the humanized dates setting is not active, the hover popup displays the date with the time, if set. Otherwise, if the date doesn't contain a time, the current behavior is kept.
• When the date doesn't contain a time, conversion to the browser's timezone it's not necessary and must be avoided.

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[tylerjmchugh]

Assuming the timezone is UTC causes issues. If I set a publicationDate with no time the application assumes 00:00:00 UTC. But then the UI converts the UTC time to my local time (-5) changing the date to the previous day.

[PascalLike]

Assuming the timezone is UTC causes issues. If I set a publicationDate with no time the application assumes 00:00:00 UTC. But then the UI converts the UTC time to my local time (-5) changing the date to the previous day.

Thank you for the feedbacks @tylerjmchugh, I refined the logic based on your observations. Now UTC is assumed only when the date contains a time indication but no timezone is specified.
Of course, in the case where there is a date without a time, it is acceptable that there is no timezone, because in this case the date can be considered as it is.

[tylerjmchugh]

As there is still a PR open for HNAP, I did some testing with iso19139 and I encountered some issues:

I set the following dates:

The titles all display as zulu:

In the index I see:

"creationDateForResource": [ "2026-01-01T00:00:00" ], "creationYearForResource": "2026", "creationMonthForResource": "2026-01", "publicationDateForResource": [ "2026-01-01T00:00:00Z" ], "publicationYearForResource": "2026", "publicationMonthForResource": "2026-01", "revisionDateForResource": [ "2026-01-01T00:00:00-04:00" ], "revisionYearForResource": "2026", "revisionMonthForResource": "2026-01", "resourceDate": [ { "type": "creation", "date": "2026-01-01T05:00:00.000Z" }, { "type": "publication", "date": "2026-01-01T00:00:00.000Z" }, { "type": "revision", "date": "2026-01-01T04:00:00.000Z" } ]

I think the changes applied in: metadata101/iso19139.ca.HNAP#471 need to be applied for resourceDate as well, in all schemas.

If I manually update it in the index myself:

"resourceDate": [ { "type": "creation", "date": "2026-01-01T00:00:00" }, { "type": "publication", "date": "2026-01-01T00:00:00Z" }, { "type": "revision", "date": "2026-01-01T00:00:00-04:00" } ]

The titles seem correct:

[tylerjmchugh]

The revision date with the recommended/browser timezone should not display as the previous day:

It seems that daylight savings is causing issues here. The editor guesses the timezone is -4 (EDT) correctly but then gnHumanizeTimeService guesses the timezone is -5 (EST) shifting to the previous day. Maybe this should be consistent with how the date input in the editor guesses the timezone?

[PascalLike]

by default gnHumanizeTimeService uses JVM timezone, but time zones definitions can change frequently and need to be updated.
An alternative may be to set a fixed Timezone in the settings, setting it to "Browser", to use the one from the browser (like in the editor) or another fixed value.

[tylerjmchugh]

I don't think this if statement is required.

YYYY-MM-DDtHH-mm-SSSZ is not valid anyways. I think moment(date) should work fine in both cases?

[tylerjmchugh]

Was this change intentional? It is not changing any logic. Only the order.

[PascalLike]

Just for readability

[tylerjmchugh]

Sorry the previous approval was a mistake. Please see comments.