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]

I encountered this a while ago but hadn't logged. Seems to be an issue on the serialization on the way out- I had previously checked with Holochain Playground and found that the value is being correctly saved in the DB. May also be an issue with fecha.parse in connection.ts and happening at the JS layer.

[Connoropolous]

oh, well... It seems the issue doesn't occur if you pass a decimal after the seconds, for milliseconds or whatever

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

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

which is fine. definitely smells like a bug, but a developer should I guess read about the system here and specify accordingly?

[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 4e1255d4 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?

[pospi]

Related to #156