API does not return milliseconds in datetimes even when present in underlying data

[ml-evs]

Just ran into this while hacking on #595.

Some combination of FastAPI/pydantic is ripping out the milliseconds in responses containing date-times. This causes the validator to get upset when it tests that a query like last_modified>2018-06-08T04:13:37Z doesn't return the original object it scraped the time from, but in reality the object has an amount of fractional seconds added onto it in the database, so it is correctly included in the "exclusive" query.

[ml-evs]

This is very frustrating, can't replicate with a MWE.

The milliseconds in the timestamp persist all the way to the response model that gets returned, so it must be the JSON encoder of FastAPI/pydantic that's doing it, but every MWE I try ends up with milliseconds being returned just fine 👿

Any ideas @shyamd? Don't know if you run into this? Think this is quite important to fix.

[ml-evs]

The answer: RFC3339 does not allow milliseconds so the response models were patched to enforce it:

optimade-python-tools/optimade/models/jsonapi.py

Lines 354 to 359 in 89227d3

	class Config:
	json_encoders = {
	datetime: lambda v: v.astimezone(timezone.utc).strftime(
	"%Y-%m-%dT%H:%M:%SZ"
	),
	}

Now need to decide whether to adjust other models/validator accordingly.