Default date serialization drops trailing zeros in the microseconds date portion.

Hello,

I picked this problem up when I was parsing a date serialized by newtonsoft in another system.

I have a date from my source (.net system) as follows:

2017-11-21 05:55:27.064100

When this date is serialized by newtonsoft it comes out like this:

{"DateCreated":"2017-11-21T05:55:27.0641"}

Note the trailing zeros were truncated. This breaks deserialization which is expecting microseconds in my java app using this format specifier: “yyyy-MM-dd’T’HH:mm:ss.SSSSSSX”

I expect date to be serialized like this: {"DateCreated":"2017-11-21T05:55:27.064100"}

I have attached code to reproduce. newtonsoft-date-issue.zip

Thanks,

Avner

[tmenier]

I just discovered this myself. Truncating those 0’s also compromises sortability of the default date format.

I understand this is just a default and it is easy to override, but does anyone have any historical perspective on how this decision was reached? (I wanted to mimic Json.NET’s default date serialization behavior in a library of my own, assuming it represents best practices, but now I’m not so sure.)

[Eli-Black-Work]

After some thought, I think that the current default is probably best, and if we need datetimes that are sortable/comparable, we should override the time format string. See https://github.com/JamesNK/Newtonsoft.Json/issues/2780#issuecomment-1363704872 for more details 🙂