What's the benefit of cluttering JSON with a constructor like new Date(...) when you can just standardize on ISO-8601 strings? JSON is not supposed to be eval'ed anymore.
JSON is JS. If I manually create a JSON document, it should also be valid in the context of code. And strings are not dates -- they are strings. That's why we have boolean and number literals.
So many other languages use JSON as a data format that keeping a weird constructor call in there would do more harm than good. Especially since you can keep the formatting code in your codebase and invoke that when you need to use that property.
We had a bug once when some logger output happened to get passed through JSON. The receiving code expected arrays of strings, but at some point one of the records happened to just contain a date. That ended up getting deserialised as a real Date object, not a string, which obviously broke. Using the same representation for different data types just seems to be asking for bugs.
The problem is that your code should have been expecting that field to be a string and nothing else, and other fields that contain dates to be a date and nothing else. In other words, if you're parsing JSON in this manner you need to apply some sort of schema to the data or have another field in the record denote the datatype. Anytime you're trying to auto-magically detect the datatype of the field, you're gonna have a bad time.
