Temporal API

[Ghostbird]

Given that Temporal is as stage 3 proposal now, and ECMAScript engine implementers are currently working to implement it¹. It would be very nice if we could work on that in Jint too.

As a starting point here's a Markdown Temporal API to do list template

Footnotes

1. … SpiderMonkey passes 96% of the tests. V8 and LibJS three quarters. JavaScriptCore 40%, and Boa is at 23% and they have either landed since the time that I wrote this slide or are still about to land a change that would get them to 32%. …
   103rd TC39 Meeting | 30th July 2024 # Temporal update & bug fixes

   ↩

[lahma]

That's a huge undertaking. Would you like to start implementing it incrementally? The https://github.com/tc39/test262 suite already has test cases for Temporal and they can be enabled by editing https://github.com/sebastienros/jint/blob/main/Jint.Tests.Test262/Test262Harness.settings.json and re-generating the test suite.

[Ghostbird]

Ah, that's very nice! I'll have a look. I can't promise that I can sink many hours into this, but we'll need to start somewhere.

[sebastienros]

https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/

[Ghostbird]

Thanks! I'm sorry I haven't managed to give this more time yet. I'm not too familiar with Jint yet. Do you think it is feasible to ship @js-temporal/polyfill and let users optionally enable it? Or would that be completely ridiculous in Jint's situation? As I understand it, polyfills only patch things that are missing, so we could slowly add the C# implementation and the polyfill would do less-and-less work, until it could be removed.

I think that would be one of the first things I'd like to try, load the polyfill and see what the consequences are.

[lahma]

Anyone can import the polyfills they need, I don't see a reason for jint to ship them. Downside with polyfills is that they perform a lot worse as they are interpreted instead of being native NET code.