2

DateTimeStamp : 2022-04-29 15:19:41.350 after serialization 2022-04-29T22:19:41.35Z instead of 2022-04-29T22:19:41.350Z

I have fixed this using below code :

public static void ServiceJsonSettings(HttpConfiguration config, IServiceMetadata serviceMetadata)
    {
        config.Formatters.Insert(0, new JsonNewtonsoftJilFallbackFormatter());
        IsoDateTimeConverter dateConverter = new IsoDateTimeConverter
        {
            DateTimeFormat = "yyyy'-'MM'-'dd'T'HH':'mm':'ss.fff'Z'",
            DateTimeStyles = DateTimeStyles.AdjustToUniversal
        };
        config.Formatters.JsonFormatter.SerializerSettings.Converters.Add(dateConverter);

    }

Now for large object serialization i am using Jil Serializer configured as below:

public static readonly Options JilOptions = new Options(excludeNulls: true, includeInherited: true,
            serializationNameFormat: SerializationNameFormat.CamelCase, dateFormat: DateTimeFormat.ISO8601);

Using both Serializer Newtonsoft and JIL the output I am getting expected result : 2022-04-29T22:19:41.350Z.

But after testing it i found JIL serializer Serializer is trimming the zeros in millisecond part if it ends with 00 for ex: DateTimeStamp : 2022-04-29 15:19:41.300 serialized to 2022-04-29T22:19:41.3Z. On the other hand newtonsoft serializer produce expected result 2022-04-29T22:19:41.300Z.

Is there any way to provide dateFormat as "yyyy'-'MM'-'dd'T'HH':'mm':'ss.fff'Z'" in JilOptions ?

Shani Bhati
  • 171
  • 1
  • 13
  • May I ask why you need exactly 3 decimal places in the serialized data? – Fildor Jan 09 '23 at 19:10
  • @Fildor it is business requirement from the business. in database millisecond are stored upto 3 decimal places so API response should have same. – Shani Bhati Jan 09 '23 at 19:21
  • 1
    _"up to"_ ... ".3Z" _is_ "up to 3 places". It is identical (in value) to "300Z". – Fildor Jan 09 '23 at 19:34
  • @Fildor then 30 millisecond and 300 ms both are .3Z ? as per the Microsoft documentation we have datetime.ToString("fff") includes any trailing zeros in the millisecond value. https://learn.microsoft.com/en-us/dotnet/standard/base-types/how-to-display-milliseconds-in-date-and-time-values The fff format pattern includes any trailing zeros in the millisecond value. The FFF format pattern suppresses them – Shani Bhati Jan 09 '23 at 19:47
  • _"then 30 millisecond and 300 ms both are .3Z ?"_ No. 3ms is ".003Z" as in "3/1000 of a second", 30ms is ".030" is ".03Z" as in "3/100 of a second" and 300ms is ".300" is ".3Z" as in "3/10 of a second". It is expressed in "fractions of a second" ( hence "f" for **f**raction ). – Fildor Jan 09 '23 at 19:52
  • @Fildor thanks got it but there should be some way to represent with trailing zeros in the millisecond value similar to newtonsoft 'fff' pattern in JIL serializer also. – Shani Bhati Jan 09 '23 at 20:00
  • If you absolutely want to, probably. I just doubted you actually need it. Haven't worked with JIL, so I don't actually know how to, though. – Fildor Jan 09 '23 at 20:04
  • Do I read that correctly that your solution works for one zero as in "350" but _not_ for 2 zeroes as in "300"? – Fildor Jan 09 '23 at 20:05
  • @Fildor yes JIL serialization for .350 it gives '.350Z' but for .300 it gives '.3Z' while newtonsoft with above configuration leads to '300Z'. – Shani Bhati Jan 09 '23 at 20:11
  • Ok, I can now confirm the behavior and NewtonSoft.Json doesn't play into it. I created a plain Console App serialized two objects. One with .300 and one with 350 and they end up as 3Z and 350Z using the ISO8601 format setting which leads me to the conclusion that this _could actually be a bug_? (Haven't found a way to get to 300Z, yet though) – Fildor Jan 09 '23 at 20:20
  • @Fildor i have also created a console app below are result with JsonConvert: 1.with settings :{"CreateDate":"2022-07-01T16:32:44.300Z","UpdatedDate":"2022-07-01T16:32:44.350Z"} // Pattern : "yyyy'-'MM'-'dd'T'HH':'mm':'ss.fff'Z'" 2. default settings :{"CreateDate":"2022-07-01T16:32:44.3","UpdatedDate":"2022-07-01T16:32:44.35"} – Shani Bhati Jan 09 '23 at 20:47

0 Answers0