Are there any plans to introduce Date/Time literals?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Are there any plans to introduce Date/Time literals?

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

{
   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.

There are other options of course. Just wanted to know if this makes
sense in principle.




--
Andrew Fedoniouk.

http://terrainformatica.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Brandon Benvie-2
On 10/8/2013 2:43 PM, Andrew Fedoniouk wrote:

> 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:
>
> {
>     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.
>
> There are other options of course. Just wanted to know if this makes
> sense in principle.

While not exactly what you want, something close can be achieved using a
tagged template:

```js
let date = ([string]) => Date.parse(string);

({
    eventType: "meeting",
    eventStarts: date`2014-11-05T13:15:30Z`,
    eventDurationHours: 4
})
```
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Mike Samuel
In reply to this post by Andrew Fedoniouk
2013/10/8 Andrew Fedoniouk <[hidden email]>:
> 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.

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.

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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Michael Haufe-2
In reply to this post by Andrew Fedoniouk


On Tue, Oct 8, 2013 at 4:43 PM, Andrew Fedoniouk <[hidden email]> wrote:
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:

{
   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.

There are other options of course. Just wanted to know if this makes
sense in principle.




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Andrew Fedoniouk
In reply to this post by Mike Samuel
On Tue, Oct 8, 2013 at 3:09 PM, Mike Samuel <[hidden email]> wrote:
> 2013/10/8 Andrew Fedoniouk <[hidden email]>:
>> 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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Andrew Fedoniouk
In reply to this post by Michael Haufe-2
On Tue, Oct 8, 2013 at 4:20 PM, Michael Haufe <[hidden email]> wrote:

>
>
> On Tue, Oct 8, 2013 at 4:43 PM, Andrew Fedoniouk <[hidden email]>
> wrote:
>>
>> 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:
>>
>> {
>>    eventType: "meeting",
>>    eventStarts: 2014-11-05T13:15:30Z,
>>    eventDurationHours: 4
>> }
>>
...
>
> http://wiki.ecmascript.org/doku.php?id=discussion:date_literal_syntax
>
> http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_syntax
>
> https://encrypted.google.com/#q=site:https%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F+%22date+literal%22
>

Thanks for links but what is the conclusion?

--
Andrew Fedoniouk.

http://terrainformatica.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Claude Pache
In reply to this post by Andrew Fedoniouk

Le 8 oct. 2013 à 23:43, Andrew Fedoniouk <[hidden email]> a écrit :

> 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:

Even if there had been a dedicated syntax to write literal dates in JS, it doesn't mean that JSON would have allowed such a representation.
For instance, the following entities have literal representation in JS, but do not exist in JSON, by the will of its designer: Infinity, NaN, and regular expressions.

Conversely, you can define a superset of JSON that doesn't parse as a JS expression.
(In fact, `JSON.parse` does already produce different results from `eval` for edge cases.)

Unrelated to JSON, note that there is already a convenient way to write down a literal date in JS, namely: `new Date("2014-11-05T13:15:30Z")`.

—Claude

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Brendan Eich-3
In reply to this post by Andrew Fedoniouk
Andrew Fedoniouk wrote:
>> http://wiki.ecmascript.org/doku.php?id=discussion:date_literal_syntax
>> >
>> >  http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_syntax
>> >
>> >  https://encrypted.google.com/#q=site:https%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F+%22date+literal%22
>> >
>
> Thanks for links but what is the conclusion?

No date literals in JS. Not worth their weight, most Dates are not
expressed as hardcoded date strings. If you need it, use an ES6 template
string.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Oliver Hunt-2
In reply to this post by Claude Pache

On Oct 9, 2013, at 1:35 AM, Claude Pache <[hidden email]> wrote:

>
> Le 8 oct. 2013 à 23:43, Andrew Fedoniouk <[hidden email]> a écrit :
>
>> 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:
>
> Even if there had been a dedicated syntax to write literal dates in JS, it doesn't mean that JSON would have allowed such a representation.
> For instance, the following entities have literal representation in JS, but do not exist in JSON, by the will of its designer: Infinity, NaN, and regular expressions.

Infinity and NaN a identifiers referencing properties on the global object — they’re not literals (nor is undefined).

These are all valid (but you shouldn’t do it):

function f(undefined, NaN, Infinity) {
// dooooooommmmmm
}


function f() {
var undefined = null /* fix that silly null vs. undefined shenanigans */, NaN = Math.sqrt(2) /* make sure nan is not rational */, Infinity = 10000000 /* this should be big enough */
}

—Oliver
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Claude Pache


> Le 9 oct. 2013 à 18:46, Oliver Hunt <[hidden email]> a écrit :
>
>
>> On Oct 9, 2013, at 1:35 AM, Claude Pache <[hidden email]> wrote:
>>
>>
>>> Le 8 oct. 2013 à 23:43, Andrew Fedoniouk <[hidden email]> a écrit :
>>>
>>> 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:
>>
>> Even if there had been a dedicated syntax to write literal dates in JS, it doesn't mean that JSON would have allowed such a representation.
>> For instance, the following entities have literal representation in JS, but do not exist in JSON, by the will of its designer: Infinity, NaN, and regular expressions.
>
> Infinity and NaN a identifiers referencing properties on the global object — they’re not literals (nor is undefined).
>
> These are all valid (but you shouldn’t do it):
>
> function f(undefined, NaN, Infinity) {
> // dooooooommmmmm
> }
>
>
> function f() {
> var undefined = null /* fix that silly null vs. undefined shenanigans */, NaN = Math.sqrt(2) /* make sure nan is not rational */, Infinity = 10000000 /* this should be big enough */
> }
>
> —Oliver

Yes, I know... Well, the next time, I will avoid to do an oversimplification in order to make my point, for there is always someone for splitting hairs. (Hopefully, RegExp literals remain. And I left as an exercise to the reader to understand what happens to -0 when transiting through JSON, and why... No, I won't discuss the answer.)

—Claude
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Jorge Chamorro Bieling
In reply to this post by Oliver Hunt-2
On 09/10/2013, at 18:46, Oliver Hunt wrote:
>
> function f() {
>   var undefined = null /* fix that silly null vs. undefined shenanigans */,
>   NaN = Math.sqrt(2)   /* make sure nan is not rational */,
>   Infinity = 10000000  /* this should be big enough */
> }

Sheesh, fix NaN, it shouldn't be a number!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Mark S. Miller-2


On Wed, Oct 9, 2013 at 10:59 AM, Jorge Chamorro <[hidden email]> wrote:
On 09/10/2013, at 18:46, Oliver Hunt wrote:
>
> function f() {
>   var undefined = null /* fix that silly null vs. undefined shenanigans */,
>   NaN = Math.sqrt(2)   /* make sure nan is not rational */,
>   Infinity = 10000000  /* this should be big enough */
> }

Sheesh, fix NaN, it shouldn't be a number!
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Andrew Fedoniouk
In reply to this post by Brendan Eich-3
I understand that in "normal" JS code date literals are kind of not
needed.  As probably in any other programming language where date
values are coming from external sources, e.g. from DB/persistent
storage.

But JS/ES is quite unique in this respect. It's data literals *are*
used as a form of persistence, and  quite a lot. Think of JS derived
syntax constructs like JSON or MongoDB query language.

If tomorrow JSON2 will appear it will come up with its own date
literals. And suddenly you will not be able to use eval() to parse
JSON. I know that eval() ideally should not be used to parse JSON but
nevertheless. I believe that it is beneficial for many reasons for the
language to include transport format (e.g. JSON literals) as part of
base syntax.



On Wed, Oct 9, 2013 at 8:29 AM, Brendan Eich <[hidden email]> wrote:

> Andrew Fedoniouk wrote:
>>>
>>> http://wiki.ecmascript.org/doku.php?id=discussion:date_literal_syntax
>>> >
>>> >  http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_syntax
>>> >
>>> >
>>> > https://encrypted.google.com/#q=site:https%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F+%22date+literal%22
>>> >
>>
>>
>> Thanks for links but what is the conclusion?
>
>
> No date literals in JS. Not worth their weight, most Dates are not expressed
> as hardcoded date strings. If you need it, use an ES6 template string.
>
> /be



--
Andrew Fedoniouk.

http://terrainformatica.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Are there any plans to introduce Date/Time literals?

Brendan Eich-3
Andrew Fedoniouk wrote:
> Iftomorrow  JSON2 will appear it will come up with its own date
> literals.

This is what people are telling you on this thread "won't happen". Of
course, it "could happen" -- but given all the things we worry about,
this one is way, wayyyy down on the list.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss