Are there any plans to introduce Date/Time literals?

Mike Samuel mikesamuel at
Tue Oct 8 15:09:13 PDT 2013

2013/10/8 Andrew Fedoniouk <news at>:
> Quite often Date values are used in data exchanges in form of JS
> literals or JSON.
> It would be beneficial if JS (and JSON as derivative) will have an
> ability to represent dates literally  . For example:

JSON can't change since it's not versioned. says
"JSON has no version number. No revisions to the JSON grammar are
anticipated. If something has a 1.0, it will inevitably get a 1.1 and
a 2.0, and everything is crap until it is 3.0. JSON is very stable."

> {
>    eventType: "meeting",
>    eventStarts: 2014-11-05T13:15:30Z,
>    eventDurationHours: 4
> }
> Technically we can allow date/time format using ISO 8601 as it is.
> That will require some additional look-ahead in tokenizer but is
> doable as far as I can tell.

Since JSON won't change, I don't see that this has much benefit over a
function that does the right thing w.r.t. month ordinal numbers.

Even if you could change JSON, ISO 8601 allows dropping seconds and
timezones which means you have to trade-off simplicity vs ease-of-use
to avoid ambiguity.

Consider the expression

    myDate1 = 2014-11-05T13:14
    myDate2 = condition1?condition2?2014-11-05T13:14:30 ...

To resolve ambiguity for date-times within deeply nested ternary
operators, you'd have to do backtracking, which you shouldn't do in
the lexer, so you have to be greedy which now means that date literals
are ok some places and not others.

Taking punctuation tokens and making them part of larger tokens
already happens in regular expression literals, and it is the source
of a lot of complexity.

More information about the es-discuss mailing list