2

I've noticed that both JSON.NET and System.Text.Json doesn't serialize the milliseconds of a datetime when the value is zero.

As in, i see values like: "3000-01-01T00:00:00" (no milliseconds), and "3000-01-01T00:00:00.999"

Here is a fiddle demonstrating the issue: https://dotnetfiddle.net/yi47EY

The issue is, we have clients that are breaking because they expect a consistent format (e.g always returning milliseconds, even when .000)

I found this reference: https://www.w3.org/TR/NOTE-datetime

Which states:

An adopting standard that permits fractions of a second must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be "unlimited")."

So, does that mean:

  1. JSON.NET and System.Text.Json is breaking the specification, because we are sending different 'formats'? or
  2. We are adhering to the specification, but all clients should be flexible to deal with the different formats?
Pure.Krome
  • 84,693
  • 113
  • 396
  • 647
RPM1984
  • 72,246
  • 58
  • 225
  • 350
  • Does this answer your question? [Force JSON.NET to include milliseconds when serializing DateTime (even if ms component is zero)](https://stackoverflow.com/questions/18193281/force-json-net-to-include-milliseconds-when-serializing-datetime-even-if-ms-com) – Roar S. Aug 11 '20 at 01:07
  • @RoarS. nope, it provides an _explicit_ format, which i can do, if need be. But, I'm asking about whether the status quo is breaking a specification or not.. In other words, i want to know the reason why the things are the way they are, before i go against the standard/common use case. – RPM1984 Aug 11 '20 at 01:22
  • The document you link to is not a specification, it's a note submitted to the W3C that advocates the use of a subset of ISO 8601. It has no relation to JSON whatsoever, nor vice versa. There is no agreed upon standard, see duplicate. – CodeCaster Aug 11 '20 at 01:26

1 Answers1

2

JSON.NET and System.Text.Json is breaking the specification, because we are sending different 'formats'?

JSON isn’t an “adopting standard” as it does not reference ISO 8601, or prescribe any particular format for date and time. In JSON they are just strings. So serializers are free to represent dates in any way they like. Both serializers choose ISO 8601, and fractional seconds are not required and often useless extra bytes.

This is the downside of JSON being radically simple.

System.Text.Json has custom converters you can use to override the default behavior of the serializer: How to write custom converters for JSON serialization (marshalling) in .NET

David Browne - Microsoft
  • 80,331
  • 6
  • 39
  • 67
  • 1
    > Both serializers choose ISO 8601, and fractional seconds are not required and often useless extra bytes. < Yep, exactly this .. but .. the output are _different_ ISO 8601 *profiles*. The question asked was/is: Given the ISO standard has different profiles AND that quote says (to me): "here are some profiles, pick one." ... doesn't it become confusing (or broken as the OP suggested) that S.T.Json is creating string results with _different_ profiles under different scenario's, to reduce the 'useless extra bytes' ? In other words, it's not consistent? – Pure.Krome Aug 11 '20 at 02:53
  • It’s a reasonable design decision to serialize each datetime with minimal fractional seconds because its expensive and/or impossible to figure out how many are necessary at the start of a serialization request. – David Browne - Microsoft Aug 11 '20 at 03:30
  • verus -> a profile that will include fractions or not. If the profile selected was to include fractions, then document/suggest a min / max fraction? – Pure.Krome Aug 11 '20 at 03:53
  • Or a general-purpose extensibility API to customize the serialization. – David Browne - Microsoft Aug 11 '20 at 12:45