Which xs:date timestamp format to use

[csaf-tools]

Which xs:date timestamp format to use

[tschmidtb51]

The first variant is preferred (especially since the offset can be e.g. -06:00) and fully in line with RFC 3339 Section 5.6.

[sustefil]

As discussed here:

#21 (comment)

Convert all observed timestamps into the consistent formatting which was agreed upon above.
Will be done as a Pull request for this issue.

[zpevma]

There are couple of edge cases, which pass the input validation, but not output one. The most extreme which doesn't make sense is -22011-11-26T00:00:00Z: perfectly passes xsd validation, but not the output one.

I suggest to:

• ignore negative dates (log error)
• ignore years > 9999 (log error)
• if no timezone is specified on the input, don't specify it on the output
• if we have UTC timezone stated by Z, replace it by +00:00
• always output in the format 2021-12-10T09:05:47.966+00:00 or 2021-12-10T09:05:47.966

[cgi1]

Clarified - Assigned for implementation.

[cgi1]

@zpevma: Please check this one and this one to be compliant with the date format desc here.

This can also be achived, by rechecking all timestamp in the end - change implemented in one PR.

[cgi1]

@tschmidtb51 / @mfd2007: Is this procedure ok? @zpevma already working on it in a local pull request.

[tschmidtb51]

There are couple of edge cases, which pass the input validation, but not output one. The most extreme which doesn't make sense is -22011-11-26T00:00:00Z: perfectly passes xsd validation, but not the output one.

I suggest to:

* ignore negative dates (log error)

That's OK.

* ignore years > 9999 (log error)

That's OK.

* if no timezone is specified on the input, don't specify it on the output

That would be invalid in CSAF. The CVRF CSAF 1.2 standard states that any timestamp with "an empty zone designator MUST be treated as having UTC offset 0 or equivalently" (see [CSAF-2.2.1-2]

* if we have UTC timezone stated by `Z`, replace it by +00:00

That's OK.

* always output in the format `2021-12-10T09:05:47.966+00:00` or `2021-12-10T09:05:47.966`

First one is OK. Second is not a valid according to RFC 3339, section-5.6.