This behavior is occurring on cveawg-test.mitre.org just now:
If PUT /cve/:id is used with a CVE Record that includes:
"containers": {
"adp": [{
"providerMetadata": {
"orgId": "b3476cb9-2e3d-41a6-98d0-0f47421a65b6",
"dateUpdated": "2026-01-01T00:00:00.123456+23:00"
},
"timeline": [
{
"time": "2026-01-01T00:00:00.123456+24:00",
"lang": "en",
"value": "something happened in the +24:00 timezone"
}
]
}],
then the CVE Record is stored with:
"containers": {
"adp": [
{
"providerMetadata": {
"orgId": "b3476cb9-2e3d-41a6-98d0-0f47421a65b6",
"dateUpdated": "2025-12-31T01:00:00.123Z"
},
"timeline": [
{
"time": "2026-01-01T00:00:00.123456+24:00",
"lang": "en",
"value": "something happened in the +24:00 timezone"
}
]
}
],
This is unlikely to come up in realistic cases. Although the PUT /cve/:id endpoint is sometimes used to submit CVE Records that have containers.adp[0].timeline, the value of containers.adp[0].timeline is usually something that was very recently retrieved in a GET /cve/:id call. In other words, it would not be stale data from before timestamp normalization, and would not be a value that was composed manually or obtained from a third party.
This behavior is occurring on cveawg-test.mitre.org just now:
If
PUT /cve/:idis used with a CVE Record that includes:then the CVE Record is stored with:
This is unlikely to come up in realistic cases. Although the
PUT /cve/:idendpoint is sometimes used to submit CVE Records that have containers.adp[0].timeline, the value of containers.adp[0].timeline is usually something that was very recently retrieved in aGET /cve/:idcall. In other words, it would not be stale data from before timestamp normalization, and would not be a value that was composed manually or obtained from a third party.