timestamp normalization allows ADPs to send data with ambiguous dates

[ElectricNroff]

This behavior is occurring on cveawg-test.mitre.org just now:

If PUT /cve/:id/adp is used with this input:

{"adpContainer": {
    "datePublic": "02/03/2025",
    "timeline": [
      {
         "time": "02/03/2025",
         "lang": "en",
         "value": "something happened on February 3 or March 2"
       }
     ]
}}

then the CVE Record is stored with:

        "datePublic": "2025-02-03T00:00:00.000Z",
        "timeline": [
          {
            "time": "2025-02-03T00:00:00.000Z",
            "lang": "en",
            "value": "something happened on February 3 or March 2"
          }
        ]

For example, if there is a new SADP who is sending date information for the first time, they may not know that the RFC3339 format is expected, and might instead choose the 02/03/2025 format. This is commonly used in the U.S. to mean February 3, but is commonly used in Europe to mean March 2. Because schema validation occurs after timestamp normalization, the 02/03/2025 value is accepted and the SADP container is added to the CVE Record. The date/time processing in CVE Services always converts it to a February 3 value, but the desired behavior is to reject the container input as ambiguous, because the date is important information for some CVE consumers, and they need to know that an unambiguous February 3 date appeared in the input that the SADP originally sent to the server.

In other words, CVE Services is converting 02/03/2025 to a compliant RFC3339 value with exactly the right number of digits, but this misses the point that CVE Services was never supposed to accept 02/03/2025 in the first place.