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. 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
