4 ms·

All I want is a datetime literal: #2018/01/31 17:00:21.2234233#. I don't even care that it isn't backwards compatible. Eventually platforms will catch up... so

• gmac 9y ago
  Is that because you want date/times in JSON? Shouldn't it include a timezone, and maybe implement ISO8601?
  • chrisseaton 9y ago
    Putting it into ES won’t change the JSON standard though.
    • mikewhy 9y ago
      Wouldn't it have to? It does stand for JavaScript Object Notation after all.
      • stephenhuey 9y ago
        This question seems reasonably sincere enough that you could attempt to answer it rather than downvote it.
      • chrisseaton 9y ago
        That's where the idea came from. But it's now a completely standalone standard, with its own grammar, that just happens to be compatible with a subset of ES.
        • epmatsw 9y ago
          Even that's not technically true. You can represent things in JSON that can't be represented in ES object literals. There's a proposal in Stage 3 to fix that though: https://github.com/tc39/proposal-json-superset https://github.com/tc39/proposal-json-superset
    • rbobby 9y ago
      It wouldn't... but it could open the door to updating the standard.
  • rbobby 9y ago
    2 things I want in JSON: 1. Datetime 2. Expand the encoding to escape '<' and '>' Being able to specify a datetime as local vs utc would also be nice... so "2018/01/31 17:35:21.2222Z" for UTC and "2018/01/31 17:35:21.2222" for local. As to the actual format used... that it's just a bikeshed argument waiting to happen. I picked y/m/d for no particular reason (well... other than my ancient preference for a simple sort key). I also picked 24 hour time for no particular reason (well... other than my ancient preference for a simple sort key). No one would really care too much one way or another what the format was (so long as it was easy to generate using common server side technologies... node, php, java, .net).
    • throwbsyxgsbend 9y ago
      You can use Unicode escapes for < and > if you need them to be escaped. (Which is unfortunate, but defense in depth I guess.)
    • gnud 9y ago
      It might be nice to transfer dates as a separate type from string. But for the love of FSM, use ISO 8601 as the format! [1] 1: https://xkcd.com/1179/ https://xkcd.com/1179/
• dangoor 9y ago
  TC39 has a pretty open process for proposals, so you can help. But “not backwards compatible” won’t fly. “Don’t break the web” is a key part of TC39’s thinking
  • rbobby 9y ago
    Haven't they already given up on backwards compatibility with things like => and for..of?
    • phpnode 9y ago
      Those are additive, they don't affect the semantics of code that was written before they were added. That is what is meant by backwards compatibility here - you never need to change existing code because of new features.
      • z3t4 9y ago
        before es6 anything added also did not break existing implementations. eg you could run es5 features in a es4 engine using polyfill and progressive enhancement/degression. maybe its time for ES to add meta and overloading - although with a huge cost of complexity !?
    • BillinghamJ 9y ago
      No? They're both backwards compatible.