Wishful Thinking - Date Literal Syntax for JSON

The simplicity of JSON or JavaScript Object Notation has established it as the preferred object serialization format used in AJAX apps, despite the fact that "X" is supposed to stand for XML. So as you'd expect, in Atlas, we use it to send and receive data to and from the server when. Essentially JSON is based on literal syntax for primitive types, arrays and objects, allowing you to specify atomic values, group them in arrays or records which can be further grouped recursively, thereby allowing you to define an arbitrary object graph (as shown visually and explained in further depth here).

However there is one wrinkle to this model. There is no literal syntax for Date objects, like there is for strings, booleans, and numbers ("abc", true, and 123). Even Regex objects can be expressed as literals such as /d{2}$/. So its not clear why the date type was ignored in the original JavaScript language design. Despite being fairly common, you are required to create dates by calling new Date(…). It seems like a big oversight. I'd be curious if there was in fact some conscious thought behind this omission.

Consequently, in our JSON serialization in Atlas we do use the Date ctor to serialize date instances, both on the server and on the client. Besides being an exception to the rule, this requires the server-side JSON parser (which can't simply eval the serialized string format to implement deserialization) to have to understand new ctor expressions, which are an inherently more flexible language construct and consequently a tad bit more complex to deal with than literal values.

This has bugged me since we first started work on Atlas. I'll go ahead and propose a syntax that’s been on my mind for just about as long: @04/15/2006@, or @04/15/2006 12:00:00 PM@. Basically I am proposing the use of "@" which reads out as "at" as a logical choice to represent date instances. The content within can be anything that is already supported by Date.parse().

Maybe something along these lines can be considered for a future version of the JavaScript/EcmaScript syntax, but then theres the question of broad availability across script engine implementations before it can be depended upon. This is where the roughly 5 year maturity period required for any new technology on the Web to be usable kicks in… bummer!