Are there any plans to introduce Date/Time literals?
news at terrainformatica.com
Tue Oct 8 22:17:51 PDT 2013
On Tue, Oct 8, 2013 at 3:09 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
> 2013/10/8 Andrew Fedoniouk <news at terrainformatica.com>:
>> 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.
I can imagine that if someone will decide to make JSON 2.0 it
will be served as application/json2 or something as such.
> http://www.json.org/fatfree.html 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.
Well, it can be not an exact ISO literal but something like:
0d2014-11-05T13:14 or even something completely different.
As of ambiguity with ternaries, it can be solved simply as
myDate2 = condition1?condition2?(2014-11-05T13:14):30 ...
In fact we can live without date literals if stock JSON.parse()
method would allow things like:
so will accept superset of JSON base specification.
As soon as browsers, databases and nodes will get it out of the box the
JSON spec will catch it up.
> 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.
That's true but at the same time regexp literals are quite convenient
as you don't need that ugly \\\\ constructions when regexp is put inside
More information about the es-discuss