ASCII_Date_Time_* do not sufficiently check valid days of a month or seconds

[jordanpadams]

🐛 Describe the bug

Per NASA-PDS/harvest#81, it looks like the PDS4 IM schematron rules do not sufficiently check the proper days for each month.

In the example in the ticket above,

<stop_date_time>2012-06-31T02:22:47.956Z</stop_date_time> 

is valid.

Additionally, this looks to validate successfully:

<stop_date_time>2012-02-30T02:22:47.956Z</stop_date_time> 

New update found 2022-02-17, issue with allowing 60 seconds. This comes back valid and it shouldn't:

<stop_date_time>2012-02-01T02:22:60.956Z</stop_date_time> 

🕵️ Expected behavior

If an invalid day of month is given, the schematron should trigger an error.

For additional test cases see #487

[rsjoyner]

I have not tested this against every variation of PDS date and date-time (e.g., ASCII_Date_Time_YMD_UTC, ASCII_Date_YMD, etc).
But this new and improved schematron rule appears to work to validate the above month-day conditions including leap-year.

<sch:pattern>
  <sch:rule context="pds:Time_Coordinates/pds:start_date_time">
    <sch:let name="type-date" value="if (contains(.,'T')) then (xs:dateTime(.)) else (xs:date(.))"/>
    <sch:let name="date-sansZ" value="translate(., 'Z', '')"/>
    
    <sch:assert test="$type-date = .">
      <title>pds:Time_Coordinates/pds:start_date_time</title>
      The value for "pds:Time_Coordinates/pds:start_date_time" does not appear to be a valid date-time: '<sch:value-of select="."/>' - '<sch:value-of select="$type-date"/>' </sch:assert>
  </sch:rule>
  <sch:rule context="pds:Time_Coordinates/pds:stop_date_time">
    <sch:let name="type-date" value="if (contains(.,'T')) then (xs:dateTime(.)) else (xs:date(.))"/>
    <sch:let name="date-sansZ" value="translate(., 'Z', '')"/>
    
    <sch:assert test="$type-date = .">
      <title>pds:Time_Coordinates/pds:stop_date_time</title>
      The value for "pds:Time_Coordinates/pds:stop_date_time" does not appear to be a valid date-time: '<sch:value-of select="."/>' - '<sch:value-of select="$type-date"/>' </sch:assert>
  </sch:rule>      
</sch:pattern>

Apparently, I cannot drop the SCH file here. So, I will do what I have done for millennia and email the updated SCH to J.Hughes.

[tloubrieu-jpl]

@rsjoyner @jshughes let us know when you can make progress on these tickets. Thanks

[jordanpadams]

Reverted changes in order to build a more sufficient test suite to ensure the solution does not break any other time formats.

[jpl-jengelke]

This is verified with the new files provided today. There is now no exception. Diff-ing the schematron and schema files shows that exactly that section identified above by @rchenatjpl was removed from the new files.

See attached test execution report.
434_execution_new_I_files.txt

PASS

[jordanpadams]

Waiting on https://pds-jira.jpl.nasa.gov/browse/CCB-350

[jimmie]

CCB discussions continuing on this.

[matthewtiscareno]

CCB discussions continuing on this.

You mean DDWG, not CCB.

The DDWG is responsible for drafting proposals for implementation. The CCB only gives an up-or-down vote to what the DDWG produces.

[jordanpadams]

Closing this as invalid. will be replaced by CCB-350 and #502