Modify schema to enforce UTC and timezones

[jayjacobs]

Currently the timestamp values in the record are all over the place (see AWG #135)

These are a list of changes the schema to enforce clean storage of time stamps:

• Modify the "timestamp" definition to reference UTC instead of GMT (Use UTC instead of GMT in JSON5 #289)
• Make the inclusion of timezones non-optional (alternatively coordinate with CVE Services to ensure their issue 1274 will handle whatever input is allowed by the schema.
• Remove "datestamp" definition field as it is not referenced or used anywhere in the schema. (the "timestamp" definition is referenced everywhere a date/time object is needed.

[ccoffin]

Discussed in 10/31/2024 QWG. Three changes suggested above by Jay.

[sei-vsarvepalli]

I would recommend if we require it we specify RFC 3339 in the documentation - being very specific about the format we want to support ISO8601 is broader - https://www.rfc-editor.org/rfc/rfc3339

[jayjacobs]

I would recommend we copy what's used in the github rest api when it accepts timezones:

This is a timestamp in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) format: YYYY-MM-DDTHH:MM:SSZ

(pulled from REST API documentation)

[ElectricNroff]

I feel that CNAs should be required to enter a timezone, but should not be required to enter UTC. When composing the relevant data (e.g., the timeline or datePublic property, which is preserved by the CVE Services server when accepting a CNA container), the CNA should be directly entering the timestamp data that they use internally. Some CNAs, especially if they have a product that is only used in one country, maintain their internal timelines in local time. They should not be doing timezone math on their side, because there is a large risk that they will screw it up, Instead, they should submit the data that they use internally, and rely on the CVE Services server to convert to UTC before the CVE Record is stored.