Are there any plans to introduce Date/Time literals?

Andrew Fedoniouk 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.

JavaScript is not versioned either in this respect.

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:

{
    eventType: "meeting",
    eventStarts: Date("2014-11-05T13:15:30Z"),
    eventDurationHours: 4
}

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
string literals.


-- 
Andrew Fedoniouk.

http://terrainformatica.com


More information about the es-discuss mailing list