DateTime serialization has non optional 3 digit millisecond component

[mursilsayed]

This PR addresses #58 using a custom DateTimeFormatter for the object serialization.

[bbakerman]

Thanks

[arijitdasgupta]

Hello, as far as I understand this PR, it'll always take produce 3-digits after the decimal point? Right?

Previously, it would be arbitrary with the amount of precision available from the input timestamp string. But have you considered the effect on nano-second level precision? For example the timestamp with complete nanosecond precision 2022-07-04T12:57:25.548234Z used to end up as 2022-07-04T12:57:25.548234Z, but after this change now it ends up as 2022-07-04T13:12:54.267Z?

Is this intentional?

Thanks!

Please let me know if the explanation, concern makes sense!

[dondonz]

Hi @arijitdasgupta yes this is an intentional change to always produce 3 digits representing milliseconds, as per the DateTime Scalar specification on this page https://www.graphql-scalars.com/date-time/#non-optional-exact-milliseconds

This DateTime Scalar specification is stricter than the RFC specification. The RFC specification of 1 or more digits led to different numbers of digits chosen and this caused a problem