date-time accepts timestamps without "T" separator between date and time

[jan-san]

According to the JSON Schema Validation spec, section 7.3.1 and ajv-formats' documentation, the date-time format should validate a string against the date-time production of RFC 3339, section 5.6.
This production requires the date and time components to be separated by "T" or "t".

The validation regex used in ajv-formats 2.1.1 however also accepts strings like "2023-01-22 11:11:11.123" with a whitespace character separating the date and time components (note the [t\s] portion):

/^\d\d\d\d-[0-1]\d-[0-3]\d[t\s](?:[0-2]\d:[0-5]\d:[0-5]\d|23:59:60)(?:\.\d+)?(?:z|[+-]\d\d(?::?\d\d)?)$/i

This issue will be addressed in version 3. I am posting this issue for troubleshooting/documentation.

A workaround for ajv-formats 2.1.1 is to add a pattern() to the schema, e.g. using a slight variation of the regular expression used in ajv-formats 3:

S.string().format('date-time').pattern(/^\d\d\d\d-[0-1]\d-[0-3]\d[tT](?:[0-2]\d:[0-5]\d:[0-5]\d|23:59:60)(?:\.\d+)?(?:[zZ]|[+-]\d\d(?::?\d\d)?)$/)

[sei-vsarvepalli]

Is this required? The use of space for the sake of readability seems to indicate that it is acceptable.

NOTE: ISO 8601 defines date and time separated by "T".
      Applications using this syntax may choose, for the sake of
      readability, to specify a full-date and full-time separated by
      (say) a space character.

[tschmidtb51]

@sei-vsarvepalli I think this is the right move as it differentiates between "iso8601" and "rfc3339". Also the ABNF clearly states in RFC 3339 Section 5.6:

   date-time       = full-date "T" full-time

And:

This date/time format may be used in some environments or contexts
that distinguish between the upper- and lower-case letters 'A'-'Z'
and 'a'-'z' (e.g. XML). Specifications that use this format in
such environments MAY further limit the date/time syntax so that
the letters 'T' and 'Z' used in the date/time syntax must always
be upper case. Applications that generate this format SHOULD use
upper case letters.

(emphasis by me)

So with regard to CSAF, I think it makes sense to limit this to the one standard way.

[sei-vsarvepalli]

@tschmidtb51
Hmm.. I am still a bit unclear but I will take your word or approach - one would think RFC and ISO format will be more straightforward to read. Within that statement you cite there is "MAY", "SHOULD" and in the addendum para in 5.6 at the bottom there is a "MAY CHOOSE" I am assuming that your take is this whole short paragraph is not relevant to the formatting but is just stating the ISO8601's potential difference from this RFC.

NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.

On the ajv regex recommended by @jan-san , all of these below examples parse okay with the ajv library, where the item 4 should not if you follow the RFC.

1. 2023-03-24T11:28:34.416213z
2. 2023-03-24T11:28:34.416213Z
3. 2023-03-24T11:28:34.416213+00:00
4. 2023-03-24T11:28:34.416213+99:99

[tschmidtb51]

[...]
Correct.

On the ajv regex recommended by @jan-san , all of these below examples parse okay with the ajv library, where the item 4 should not if you follow the RFC.

True. I guess the more precise regex is:

S.string().format('date-time').pattern(/^\d\d\d\d-[0-1]\d-[0-3]\d[tT](?:[0-2]\d:[0-5]\d:[0-5]\d|23:59:60)(?:\.\d+)?(?:[zZ]|[+-][0-2]\d:[0-5]\d)$/)