Critical bug: JSON Date format will vary with browser "Accept-Language" request header

[josundt]

In the latest NuGet package Breeze.Server.ContextProvider (1.6.6), in the method Breeze.ContextProvider.BreezeConfig.CreateJsonSerializerSettings(), the format string currently used for the IsoDateTimeConverter will cause DateTime and DateTimeOffset values to serialize differently with different "Accept-Language" request header values to BreezeControllers:

      jsonSerializerSettings.Converters.Add(new IsoDateTimeConverter {
        DateTimeFormat = "yyyy-MM-dd\\THH:mm:ss.fffK"
        // DateTimeFormat = "yyyy'-'MM'-'dd'T'HH':'mm':'ss.FFFFFFFK"
      });

Different cultures use different separator characters between year/month/day and hours/minutes/seconds. The problem with the format string in your code is that the IsoDateTimeConverter interprets dash and colon characters as special placeholder symbols to be replaced with the locale specific separators. Locale seems to be decided by the "Accept-Language" request header (not by Thread.CurrentThread.CurrentCulture which I believed to be the case initially, since ASP.NET by default automatically sets this by parsing the "Accept-Language" request header).

If you test an ASP.NET WebApi2 Breeze Controller with a browser where language is set to f.ex. "Norwegian bokmål", the "Accept-Language" request headers will be "nb-NO", and all dates in the JSON data returned from the controller will be wrong, culture relative, non-ISO-8601-compliant, since the hours/minutes/seconds separator for Norway is '.' (notice the period character used as time separator):

2018-02-21T17.05.00.000+00:00

To use non-culture-relative separators in the IsoDateTimeConverter format string, you need to put single-quotes around them.

The correct format for ISO-8601 date format (with only 3 second fraction digits to support IE9) should be:

"yyyy'-'MM'-'dd'T'HH':'mm':'ss.FFFK"

Please fix this as soon as possible and release a new version of the NuGet package - this is a current production issue in our product. We have found a temporary workaround, but this is clearly a bug on your end.

[steveschmitt]

Thanks, I never noticed this! The fix will be in the next release, which we will try to do soon.

[notiedowns]

Hi there. I am experiencing a similar problem in version 1.7.0 with finnish date/times, which use a '.' to seperate both the date components and the time components. One way I can replicate this problem is to use Chrome and promote finnish to the top of my language list using the 'Move to the top' option. Valid dates sent from the server result in null, or in some cases 'Invalid Date', on the client. E.g. DateTime.Now.ToString() which produced "19.3.2018 9.31.51" was not recognized as a valid date.

[steveschmitt]

I don't think we ever changed the code - yet I cannot reproduce the problem. Maybe because I'm using .NET 4.7.1 now? Or Json.Net 12.0?

Is this still a problem?

[jtraband]

cannot repro