Should we include a DurationFormat polyfill?

[justingrant]

Should we bundle a polyfill for Intl.DurationFormat so that Duration.p.toLocaleString will work?

There seem to be a few of these polyfills around:

• https://formatjs.io/docs/polyfills/intl-datetimeformat/
• https://www.npmjs.com/package/durationformat-polyfill (source: https://github.com/fullcalendar/temporal/tree/main/packages/durationformat-polyfill/src)

[ptomato]

I'm in favour of it, but at the time of writing neither of the listed ones seem to be functioning; the formatjs one currently logs TODO instead of the actual formatting part and the other one is an empty package.

[justingrant]

Lol, I didn't actually dig in to see if those polyfills did anything. Although the second one does look like there's runtime code in there (see https://github.com/fullcalendar/temporal/blob/main/packages/durationformat-polyfill/src/index.ts), not sure why the package is empty. No idea if it works, though!

[12wrigja]

This isn't a direct polyfill, more a ponyfill, but one implementation was contributed to Closure recently for use within Google: https://github.com/google/closure-library/blob/master/closure/goog/i18n/durationformat.js

I'd be worried about the relevant code-size costs to getting this right: the Closure version strongly depends on accessing a bunch of gencode that comes from CLDR to get all the relevant pattern parts and symbols. Within the Closure Compiler ecosystem, this is mostly OK because we can do per-locale compilation and optimize out most of the rest of the symbols, but this isn't feasible in the OSS community to my knowledge.

[jakobfdev]

https://github.com/js-temporal/temporal-polyfill/issues/277 Typing is not correct at least in one place because a polyfill for DurationFormat is missing.

the formatjs polyfill has been developed throughout the last year. tests only show english, but german also yields good results. Maybe reconsider including it - the types would help nonetheless.