proposal-temporal VS proposal-error-cause

In the TypeScript/JavaScript world the only thing called "Temporal" that I was aware of is the Stage 3 proposal for an excellent new date and time module:

https://tc39.es/proposal-temporal/docs/

Time Zone Canonicalization: Stacked on Temporal to improve handling of changes to the IANA Time Zone Database.

Roll-on Temporal!

There is a list of polyfills at the bottom of the page that can be used in production. https://github.com/tc39/proposal-temporal

:::note When using remote APIs, we often have the possibility to generate the types automatically from a JSON schema for REST APIs, from protobuf files for gRPC-based APIs, from a database schema, etc. You might even be using an external API through an SDK that already provides you with all types. In such cases, the creation of specialized Error classes is not mandatory. However, it might still be a good idea to do so to provide application-specific errors rather than bubbling up 3rd-party low-level errors. For such cases, the upcoming Ecma TC39 proposal for Error Cause is useful as it allows to chain errors. Polyfills exist: Pony Cause or error-cause. :::

Error Cause : .cause property on all Error types slides.

The impact and cause provides the most value when paired with the other, and that's what Error Cause enables and what Pony Cause is is a ponyfill for and provides helpers for.

Well, we have error-cause on stage-3 for the same and with which we could do something like:

Error Cause: Enhancing errors with a distinct "cause".

Error Cause