nekevss

The specification reached stage 4 just yesterday. That was the motive behind the blog post :)

I believe V8 / chrome bundles IANA time zones into the zoneinfo64 resource bundle. I'm not actually sure they hit the system tzdb at all.

Yep, temporal_rs is designed with native Rust use in mind, so you should be able to use temporal_rs directly wherever you'd use jiff or chrono.

That being said, the library is designed to be specification conformant and with EcmaScript implementations in mind. There are some specific API choices made specifically for those clients.

That being said, we are always looking for feedback regarding the native Rust API. So feel free to try temporal_rs out and provide whatever feedback you'd like :)

Typically time zone data is updated in IANA's time zone database. That data would need to be updated in the implementation. In this case, the browser would need to update their time zone data.

Super happy to see Temporal accepted!

Congrats to all the champions who worked super hard on this for so long! It's been fun working on temporal_rs for the last couple years :)

The library used for V8's temporal implementation is in Rust too ;)

I don't know if that's totally fair to Chrome. The specification was undergoing a lot of changes at the time, and V8 decided to wait for the specification to stabilize; meanwhile, Anba kept working on the implementation for FireFox. Additionally, the version of Temporal that Deno exposed last year was the heavily out of date to the most recent specification and had a large portion of the specification that was not even implemented.

For the engine, the answer is yes, Intl and Temporal are feature flagged due to the dependencies. What I suspect they’re comparing above is the CLIs, which is completely different than the engine. I’d have to double check for the CLI. If I recall correctly, we include all features in the CLI by default.

Yeah, the majority of the difference is from the Unicode data for Intl along with probably the timezone data for Temporal.

Yeah! I found out about Brimstone just the other day! Its definitely interesting! One optimization that they have that Boa needs to implement is ropes for our string type :)

Huh! TIL. I'll have to look into that, I'm curious how it works. Although, now that I think about it, that does make sense.

Thanks! It's always nice to talk and answer questions about the project!

The hope of the experiments is to hopefully find an API that can be used and allow for the GCs to be more swappable. At least that's my personal hope.

We really have to dig into the experimentation and rewrite before knowing for certain.

Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ...

I don't think I've actually heard of rsgc before. It's definitely interesting to see playXE put it together. I know that they'd been working on starlight at one point, so it'd be interesting to see takeaways from it.

To get to your question on the existing GCs, so far the answer is we don't truly know. We really need to do some GC experiments and test different options in Boa with JavaScript. There are not really that many GC crates out there of which I'm aware. There rust-gc's `gc` crate, dumpster, and `arena-gc` (tack on rsgc). But of those, the `gc` crate truly has the best API that we've used in Boa, but the performance is not ideal amongst other optimizations. It would be nice to preserve that API while improving the performance as well. But that remains to be seen.