Variance in RFC3339 "published" timestamps?

[woodruffw]

Hello again! I'm tracking down another pip-audit bug: pypa/pip-audit#416

In this case, a user is reporting that we're currently crashing because we fail to parse an RFC3339 timestamp. I looked into it, and the timestamp is well-formed, but slightly different from every other timestamp we've seen from OSV: it contains a microseconds field, whereas every other OSV report has had just seconds resolution in its published timestamp.

For example, one of the timestamps we expect:

2019-08-24T14:15:22Z

...and one of the ones seen by the user:

2022-10-22T00:00:27.668938Z

This is technically not a bug on OSV's side since the schema only says RFC3339, and doesn't restrict its resolution/precision. But I wanted to bring it to your attention anyways, since I figured it might be a case of timestamps being relaxed internally.

[woodruffw]

(Separately, I wonder if it might make sense to redefine the schema to enforce seconds-only precision -- having the microseconds in the published timestamp probably doesn't convey anything of value to most consumers and potentially makes naive timestamp comparison a little harder.)

[oliverchang]

Closing in favour of the issue on osv-schema's side!

[evverx]

I wonder if it would be possible to turn this into a documentation issue at least? At this point it isn't clear what exactly those fields should look like and how precise the precision should be and it makes it harder than necessary to edit OSV issues like google/oss-fuzz-vulns#25 manually. I think a paragraph saying how to generate them using date/Python/Go would help (because for example by default, date --rfc-3339=ns -u generates timestamps like 2022-12-16 09:59:53.491090155+00:00 and that's not what should go to the database). Looking at the OSV code I suspect that in general timestamps that time.Parse(time.RFC3339) can parse should probably do but that set of timestamps is larger than what is allowed by the specification.