Allow time zone designators in temporal coverage times

[rmz-oz]

Fixes #2840

Times with an offset like 11:50:00-09:00 failed with "Time must be formatted as HH:MM:SS", but EML types time as xs:time, which allows Z or +/-hh:mm and fractional seconds. validateTimeFormat now strips those before the HH:MM:SS check, and malformed offsets like -9:00 or -15:00 are still rejected. Tests are in EMLTemporalCoverage.spec.js.

[robyngit]

Thanks @rmz-oz for taking this on and adding tests! This timezone issue has come up a few times recently. Editors will really appreciate the fix!

Just an edge case, but validateTimeFormat() allows 24:00:00.1 (>24 hrs) because the fraction is removed before the hour 24 check. I've added an inline suggestion that demonstrates the issue.

Accepting timezones and fractional seconds also affects the existing range validation. These values now pass the format check, but isGreaterTime() still compares time strings, so it doesn't always order them correctly. For example, with both dates set to 2020-01-01:

• Begin 11:50:00+02:00, end 11:00:00+01:00: should be valid (09:50 to 10:00 UTC), but fails. Reversing this range incorrectly passes.
• Begin 11:50:00.1Z, end 11:50:00.12Z: should be valid, but fails.

We should update the range comparison to account for offsets and preserve fractional seconds, and add isValid() tests for these ranges.

Happy to help with the comparison logic or tests if needed. Thanks again for working on this!

[robyngit]

Hour 24 should only allow a zero fraction (along with 0 minutes and 0 seconds). This adds a failing case and checks that a zero fraction is still accepted:

Suggested change

	it("should require zero fractional seconds when the hour is 24", function () {
	var m = new EMLTemporalCoverage();
	expect(m.validateTimeFormat("24:00:00.1")).to.be.a("string");
	expect(m.validateTimeFormat("24:00:00.000Z")).to.equal(true);
	});