Date literals

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Wed Nov 19 14:40:30 PST 2008


Peter Michaux wrote:
> All the data types in ES3 listed in section 15 have literals version
> (e.g. {} for Object, [] for Array etc) except for Date. Is there any
> reason that the Kona 15.9.1.15 "Date Time string format" could not be
> a literal form for date objects?
> 
> YYYY-MM-DDTHH:mm:ss.sssTZ
> 
> The 'T' in the middle makes this identifiable as a date literal
> similar to how the 'e' or 'E' of an exponential number literal works.

When lexing this syntax, the lexer would recognize the tokens

  N - N - N : N : N .

where N is a NumericLiteral, before seeing that the next 'sssTZ'
is invalid and then having to backtrack 10 tokens. This requires
something like an LL(*) parser; it is not LL(k) for any finite k
(because each NumericLiteral can be an arbitrary number of
characters), or in any similar nicely-behaved grammar category.
Please don't add syntax like this.

> It would be beneficial to have a date literal as then a JSON object
> could have date literal values and still be parsed quickly with eval.

I'm not sure that is consistent with the general design philosophy of
JSON, which is to have a minimal set of built-in types. Typically
a JSON-based protocol would just use a string for this. Extending the
set of JSON types at this point would result in breakage of existing
JSON parsers. Besides, extending JSON is not within the scope of the
ES3.1 standard development.

For ECMAScript itself, there's nothing wrong with 'new Date("...")',
IMHO.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list