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.

[tylerjmchugh]

metadata101/iso19139.ca.HNAP#471 updates the zuluDate variable in the index so that it is only set when a timezone is specified. Shouldn't the same be done here for the other schemas?

[PascalLike]

metadata101/iso19139.ca.HNAP#471 updates the zuluDate variable in the index so that it is only set when a timezone is specified. Shouldn't the same be done here for the other schemas?

Since this can be handled on a schema-by-schema basis, I would leave this option to the communities of interest to discuss.

@tylerjmchugh are there any other specific schemas you use that you think this is important for?

[tylerjmchugh]

metadata101/iso19139.ca.HNAP#471 updates the zuluDate variable in the index so that it is only set when a timezone is specified. Shouldn't the same be done here for the other schemas?

Since this can be handled on a schema-by-schema basis, I would leave this option to the communities of interest to discuss.

@tylerjmchugh are there any other specific schemas you use that you think this is important for?

Fair enough I just thought we'd want some consistency. No issue for us since we currently only use iso19139.ca.HNAP

[tylerjmchugh]

Tested seems to work as expected