Our client wanted to show the date and time values in the browser exactly as they are in the database, and we are storing them as UTC in the database.

At first we had some problems with the serialization and Javascript side. The DateTime values got shifted twice - at first to match the local time zone of the machine and then to match the time zone in the browser. We fixed it by adding a custom Converter to the JavaScriptSerializer. We marked the DateTime to be of DateTimeKind.Utc in the Serialize override. It was a bit hard to feed the data back from the Serialize but we found some Uri hack which helped to return DateTime values in the same JavaScriptSerializer /Date(286769410010)/ format but without shifting to the local time. On the Javascript side we patched the KendoUI JS library to offset the constructed Date() objects so they appear as if they are UTC.

Then we started to work on the other side, deserialization. Again, we had to adjust our code to use a custom stringify instead of JSON.stringify, which again offsets the data when converting from the local time to UTC. Everything seemed good so far.

But look at this test:

    public void DeserialiseDatesTest()

    {

        var dateExpected = new DateTime(1979, 2, 2,

            2, 10, 10, 10, DateTimeKind.Utc);



        // this how the Dates look like after serializing

        // anothe issue, unrelated to the core problem, is that the  might get stripped out when dates come back from the browser

        // so I have to add missing  or else Deserialize will break

        string s = \/Date(286769410010)\/;



        // this get deserialized to UTC date by default

        JavaScriptSerializer js = new JavaScriptSerializer();



        var dateActual = js.Deserialize<DateTime>(s);

        Assert.AreEqual(dateExpected, dateActual);

        Assert.AreEqual(DateTimeKind.Utc, dateActual.Kind);



        // but some Javascript components (like KendoUI) sometimes use JSON.stringify 

        // for Javascript Date() object, thus producing the following:

        s = 1979-02-02T02:10:10Z;



        dateActual = js.Deserialize<DateTime>(s);

        // If your local computer time is not UTC, this will FAIL!

        Assert.AreEqual(dateExpected, dateActual);



        // and the following fails always

        Assert.AreEqual(DateTimeKind.Utc, dateActual.Kind); 

    }

Why does JavaScriptSerializer deserialize /Date(286769410010)/ strings to UTC time but 1979-02-02T02:10:10Zto local time?

We tried to add a Deserialize method to our custom JavascriptConverter but the problem is that the Deserialize is never called if our JavascriptConverter has the following types:

    public override IEnumerable<Type> SupportedTypes

    {

        get { return new List<Type>() { typeof(DateTime), typeof(DateTime?) }; }

    }

I guess, Deserialize would be called only if SupportedTypes contained types of some complex entities which have DateTime fields.

So, JavaScriptSerializer and JavascriptConverter have two inconsistencies:

• Serialize takes into account simple types in SupportedTypes for every data item, but Deserialize ignores it for simple types


• Deserialize deserializes some dates as UTC and some - as local time.

Is there any simple way to fix these issues?
We are a bit afraid to replace JavaScriptSerializer with some other serializer because maybe some of the 3rd party libraries we are using, are relying upon some certain features/bugs of JavaScriptSerializer.