Fix and test use of dates. fecha.parse usage is too strict and fails to parse dates without milliseconds given

[Connoropolous]

It seems the issue doesn't occur if you pass a decimal after the seconds, for milliseconds

This input:
hasPointInTime: "2022-02-20T01:30:15.01-08:00"

Became this:
hasPointInTime: "2022-02-20T09:30:15.010Z"

without passing milliseconds you get back null. However, we know the values are saved to the db so its just an issue with client side decoding of fields.

an issue with fecha.parse in connection.ts and happening at the JS layer.

@pospi also said:
Add tests to ensure all necessary date formats are valid for DateTime fields in search fields (dates, date + time, date + time + seconds, date + time + seconds + millis).

May want to swap out the URI and DateTime GraphQL scalar resolvers; consider using https://github.com/Urigo/graphql-scalars.

[pospi]

Interesting. Those fields are using chrono::datetime::DateTime<FixedOffset> in the backend, which I think accepts either format.

My tests are showing (checking the DHT through Playground)-

• 2019-11-19T04:29:45.000Z is stored as 2019-11-19T04:29:45+10:00 (picking up my system TZ), returned as null
• 2022-02-20T01:30:15.000-08:00 is stored as 2022-02-20T19:13:15+10:00 (timezone being coerced, uh-oh), returned as null
• 2022-01-10T01:30:15Z is stored as 2022-01-10T11:30:15+10:00 (UTC being converted to local time), returned as null

Not sure how you managed to get a value returned from the backend. There may also be other conversions happening in the fecha parsing behaviour because I just did 4e1255d and can now get 2022-01-10T01:30:15Z returned in the same format it was passed in as.

So, definitely some weird stuff with the chrono crate going on that needs to be investigated. I guess converting from a DateTime<FixedOffset> .into() another DateTime<FixedOffset> causes some timezone conversion to happen?