Missing support for timestamps/datetime in grammar

[CasperWA]

The grammar is currently missing support for timestamps (or datetime.datetime in terms of Python types).

The relevant section in the spec may be found here.

Specifically we need to recognize timestamps as values being of the form specified by RFC 3339 Internet Date/Time Format and then turn them into datetime.datetime objects if they are OK, otherwise, the implementation should return a 400 Bad Request.

[fekad]

This is a tricky one: The grammar is perfectly aligned with the specification and interprets the datetime as a string (There is nothing missing there)

As far as I can see there are two possible solutions:

• In the case of MongoDB you could say that if you have a comparison (<,>,etc.) with a string that string can only be a datetime oject because - as far as I know - mongodb doesn't support string comparisons, but you will still have problem with the = operator. This approach could also be too restrictive for other backends...
• Somehow you must define which properties are timestamp properties and you parse only those if there is a comparison with them. The parsing could happen in the FilterTransformer but keeping in mind that the names of the datetime properties depend on which endpoint you query.

[CasperWA]

In agreement in room 4 (CECAM 2020), this will be implemented in the FilterTransformer, possibly as a pre-processing matching the properties with datetime type values.

[ml-evs]

In agreement in room 4 (CECAM 2020), this will be implemented in the FilterTransformer, possibly as a pre-processing matching the properties with datetime type values.

Closing this for the reasons above: FilterTransformers now have access to field types and can appropriately handle the OPTIMADE timestamp type.