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

[avvi00]

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.)

[JamesNK]

There is no way to know how many zeros a deserialized date has so it can't be re-serialized automatically in the exact same format.

Modify it here if you want to be explicit - https://www.newtonsoft.com/json/help/html/P_Newtonsoft_Json_JsonSerializerSettings_DateFormatString.htm

[Eli-Black-Work]

It looks like this is because Newtonsoft is using "yyyy'-'MM'-'dd'T'HH':'mm':'ss.FFFFFFFK" instead of "yyyy'-'MM'-'dd'T'HH':'mm':'ss.fffffffK". Using fffffff will keep the digits, even if they're 0, but FFFFFFF won't 🙂

See https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings#FFFFFF_Specifier

[Eli-Black-Work]

I've filed a new issue for this: #2780

[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 #2780 (comment) for more details 🙂