What does HackerNews think of proposal-temporal?

> I think we need something like this:

> 2022-11-23T08:52:02!Europe/London

There is a IETF standard proposal, which is very closed to getting finalised, that defines a similar format:

    2022-11-23T08:52:02+01:00[Europe/London]

ref: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-...

It's already in use by the Temporal TC39 proposal, which defines new types for working with temporal data in JavaScript.

ref: https://github.com/tc39/proposal-temporal

they might get built-in https://caniuse.com/temporal? (https://tc39.es/proposal-temporal/docs/) (https://github.com/tc39/proposal-temporal)

> NOTE: Although this proposal's API is not expected to change, implementers of this proposal MUST NOT ship unflagged Temporal implementations until IETF standardizes timezone/calendar string serialization formats. See #1450 for updates.

it's basically already accepted. Stage 3 means it's basically ready for a preview implementation and stage 4 means passed for "official" ecmascript inclusion

Regarding fixing Date, Temporal hit stage 3 recently: https://github.com/tc39/proposal-temporal

There’s work on new JS standard called Temporal that’s a stage 3 proposal. People should be using its poly fill instead of other data libraries where possible.

https://github.com/tc39/proposal-temporal

JS standard libraries are forever. It pays to take a bit more time and get it right.

For new code, I think most JS devs have already switched to using the class syntax. Also FP in JS is alive and well if you want to avoid dealing with prototype chains altogether.

I think we can all agree the Date API sucks, but life can still be good if you just give in and include a date library. Also, there's some light at the end of the tunnel with Temporal proposal coming along [1].

Object.keys returning string[] is purely a TypeScript design decision, coming from how TypeScript chooses to model object subtyping [2].

  type Foo = {
    a: string
  }
  
  const keysOfFoo = (obj: Foo) => Object.keys(obj)
  
  const foo = {a: '', b: 5}
  keysOfFoo(foo)

The fact that this passes type checks is a conscious TS design decision that comes with both advantages and disadvantages. It wouldn't have to be this way; Exact types [3] could potentially be used to describe that if the type is exactly Foo, it's safe to assume Object.keys(foo) is (keyof Foo)[].

For first class tuples (and records), there's a stage 2 EcmaScript proposal coming along [4]. There's of course also the readonly [] type in TypeScript if you only need the safety of not accidentally pushing to an "immutable" array. First class language support could have nice additional features though, like strict equality.

Anyways, if these are the things you don't like about JS/TS, I don't think AssemblyScript will be the answer for you, as the goals of that language seem to be entirely different from "fixing" old JS cruft. Apart from the i32, i64 stuff I guess.

[1] https://github.com/tc39/proposal-temporal

[2] https://github.com/Microsoft/TypeScript/pull/12253#issuecomm...

[3] https://github.com/microsoft/TypeScript/issues/12936

[4] https://github.com/tc39/proposal-record-tuple

> `DateTime` should probably be split...

https://github.com/tc39/proposal-temporal

Formatting is fine. Take a look at `Intl.DateTimeFormat`[1]. Then there is a proposal for `Temporal`[2] which will make handling a lot easier.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2]: https://github.com/tc39/proposal-temporal

Please review and contribute your views on the TC39 Temporal proposal. There’s a polyfill to play with now...

https://github.com/tc39/proposal-temporal

There’s a stage 1 proposal for better date/time features

https://github.com/tc39/proposal-temporal