Because those are javascript primitive types, which json is built around in the first place. Date is not a javascript primitive, and is therefore not included.
If we need to follow that logic (to include useful non-primitives) we would end up with a clusterfuck of a spec that noone would want to implement.
Except that if your application is a generic client that doesn't know anything about data model of the documents it's manupulating. For example, very limited type information is the primary issue JSON can't be used in truly RESTful APIs as JSON has no hyperlinks. Myriad of standards were invented to propagate metadata (mostly, type information) with the documents.
> Except that if your application is a generic client that doesn't know anything about data model of the documents it's manupulating
This hypothetical generic client always comes up in discussions of data formats and RESTful APIs. But I've never understood what use it could be. It seems to me that any meaningful software (i.e., anything beyond a debugging tool) that would consume data or an API would need a more specific UI than a tree view with links.
Well, I have a typical CRUD webapp that has a lot of places where user just has to edit a table with properties. I don't really like that unless server has a non-standard way to provide information on schema (luckily, Tastypie does that for me), I'll have to re-declare every model's field at client side.
XML, Schemas, XML-RPC, SOAP and Thrift were all invented to solve those things. It got to verbose, so JSON was created to make thing simple again. If we add back all the staticness, we'll end up where we started.
