Are there any plans to introduce Date/Time literals?
While not exactly what you want, something close can be achieved using a tagged template:
let date = ([string]) => Date.parse(string);
({
eventType: "meeting",
eventStarts: date`2014-11-05T13:15:30Z`,
eventDurationHours: 4
})
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.
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.
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.
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.
On Tue, Oct 8, 2013 at 4:20 PM, Michael Haufe <tno at thenewobjective.com> wrote:
Thanks for links but what is the conclusion?
Le 8 oct. 2013 à 23:43, Andrew Fedoniouk <news at terrainformatica.com> 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").
Andrew Fedoniouk wrote:
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.
On Oct 9, 2013, at 1:35 AM, Claude Pache <claude.pache at gmail.com> wrote:
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 */
}
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.)
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!
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.
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.
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.
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