On Tue, Oct 8, 2013 at 3:09 PM, Mike Samuel <mikesam...@gmail.com> wrote: > 2013/10/8 Andrew Fedoniouk <n...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
