Allow non UTC lastUpdateTimestamp

[stevenwinship]

What this PR does / why we need it:

Which issue(s) this PR closes:#12349

• Closes Fix update time stamp check to not assume UTC #12349

Special notes for your reviewer:

Suggestions on how to test this:

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

Additional documentation:

[coveralls]

coverage: 24.9% (+0.02%) from 24.881% — 12349-fix-update-metadata-not-assuming-utc-timestamp into develop

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:12349-fix-update-metadata-not-assuming-utc-timestamp

ghcr.io/gdcc/configbaker:12349-fix-update-metadata-not-assuming-utc-timestamp

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.

[landreev]

I may be missing something, but I'm not sure if this is the right way to address the issue.
We do NOT want to allow "non UTC lastUpdate timestamps". The method should never see any timestamps other than in UTC (with the "Z"). That's how Dataverse reports them, regardless of where the system lives. And from what I understand, in the workflow for which the API is designed, this timestamp will always come from the output of our APIs.
For example, in the context of the test in FilesIT.java, it will be the output of /api/files/<id>, with something like

        "dataFile": {
             ...
            "publicationDate": "2026-04-20",
            "directoryLabel": "data/subdir1",
            "lastUpdateTime": "2026-04-20T20:25:05Z",
            "fileAccessRequest": true
         }

So, the way the format was hardcoded in validateInternalTimestampIsNotOutdated(), as

DateUtil.parseDate(sourceLastUpdateTime, "yyyy-MM-dd'T'HH:mm:ss'Z'")

was in fact correct - I think it's fair to reject any other formats there. What was not correct was that it was parsed ignoring the time zone completely, so it defaulted to local. But it just needs to force the UTC, aka "+00:00" - and then everything will just work. I think?

[landreev]

DateTimeFormatter.ISO_INSTANT is what we want here, I believe.
That will force the "2011-12-03T10:15:30Z"-like format; and the resulting date will be parsed as UTC.

[stevenwinship]

Closing