Parsing a Auto-Generated .NET Date Object with Javascript/JQuery

Question

There are some posts on this, but not an answer to this specific question.

The server is returning this: \"/Date(1304146800000)/\"

I would like

Answer 1

The link from Robert is good, but we should strive to answer the question here, not to just post links.

Here's a quick function that does what you need. http://jsfiddle.net/Aaa6r/

function deserializeDotNetDate(dateStr) {
  var matches = /\/Date\((\d*)\)\//.exec(dateStr);

  if(!matches) {
    return null;
  }

  return new Date( parseInt( matches[1] ) );
}

deserializeDotNetDate("/Date(1304146800000)/");

Answer 2

Since you're using jQuery I've extended its $.parseJSON() functionality so it's able to do this conversion for you automatically and transparently.

It doesn't convert only .net dates but ISO dates as well. ISO dates are supported by native JSON converters in all major browsers but they work only one way because JSON spec doesn't support date data type.

Read all the details (don't want to copy blog post content here because it would be too much) in my blog post and get the code as well. The idea is still the same: change jQuery's default $.parseJSON() behaviour so it can detect .Net and ISO dates and converts them automatically when parsing JSON data. This way you don't have to traverse your parsed objects and convert dates manually.

How it's used?

$.parseJSON(yourJSONstring, true);

See the additional variable? This makes sure that all your existing code works as expected without any change. But if you do provide the additional parameter and set it to true it will detect dates and convert them accordingly.

Why is this solution better than manual conversion? ^{(suggested by Juan)}

1. Because you lower the risk of human factor of forgetting to convert some variable in your object tree (objects can be deep and wide)
2. Because your code is in development and if you change some server-side part that returns JSON to the client (rename variables, add new ones, remove existing etc.), you have to think of these manual conversions on the client side as well. If you do it automatically you don't have to think (or do anything) about it.

Two top reasons from the top of my head.

When overriding jQuery functionality feels wrong

When you don't want to actually override existing $.parseJSON() functionality you can minimally change the code and rename the extension to $.parseJSONwithdates() and then always use your own function when parsing JSON. But you may have a problem when you set your Ajax calls to dataType: "json" which automatically calls the original parser. If you use this setting you will have to override jQuery's existing functionality.

The good thing is also that you don't change the original jQuery library code file. You put this extension in a separate file and use it at your own will. Some pages may use it, others may not. But it's wise to use it everywhere otherwise you have the same problem of human factor with forgetting to include the extension. Just include your extension in some global Javascript file (or master page/template) you may be using.