The rationale for this particular format is that a forward slash "/" would not normally need to be escaped, so an escaped forward slash "\/" stands out as something out of the ordinary. Of course, once this string is deserialized, it is stored in memory as the string "/Date(T)/".
What I find extremely frustrating about this format is the fact that even if my application is entirely in .net (no other frameworks involved, such as Java or Python), I cannot pass the result of deserializing this JSON string to another .net web service. For instance, if I have one web service call that returns a DateTime object in this manner, I cannot simply pass that string in to another web serve and expect it to be deserialized; an exception will be raised.
The above information is available from many sources. What I have to offer here is my personal solution to the problem.
Unfortunately, this still leaves me with the task of invoking the function that I've written on every object I get from a .net web service call that could possible contain these odd date strings. However, this function does give me date objects that I can pass to another web service call.
The bottom line, though, is that this is a temporary workaround until there is widespread adoption of the ES5 standard. Once that happens, your grandchildren may abandon this sort of workaround. In the meantime, remember that these literals contain escaped slashes "\/" that ordinarily do not appear in JSON strings. Since I use jQuery to get these DateTime strings from the .net web services, it might make sense to write an extention to jQuery to search for these.