You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 14, 2021. It is now read-only.
I have just tried v1.2.4 (latest) of the Intl polyfill.
According to #117 this issue should have been fixed by PR #146 .
Unfortunately, my latest tests indicate, that the opposite is still the case...
(function(){vardate=newDate(2016,0,1);// January, 1st 2016varlocale="en-us";// Other locales won't work as well, btw.varformat={month: "long"};// Valid date format according to the Intl spec.// Use the IntlPolyfill version of Date.toLocaleString even if the environment won't// actually need the polyfill varstr=IntlPolyfill.__localeSensitiveProtos.Date.toLocaleString.bind(date)(locale,format);if(str!=="January"){thrownewError("Intl polyfill is still defunct. Expected: 'January', got: '"+str+"'!");}})();
The result when executing the code abote is Jan. And that is clearly not the expected result when using the formatter { month: "long" }.
I can confirm that the code above yields the correct result, when using v1.1.0 of the Intl polyfill.
So I assume a regression bug.
The text was updated successfully, but these errors were encountered:
I have just tried v1.2.4 (latest) of the Intl polyfill.
According to #117 this issue should have been fixed by PR #146 .
Unfortunately, my latest tests indicate, that the opposite is still the case...
The result when executing the code abote is
Jan
. And that is clearly not the expected result when using the formatter{ month: "long" }
.I can confirm that the code above yields the correct result, when using v1.1.0 of the Intl polyfill.
So I assume a regression bug.
The text was updated successfully, but these errors were encountered: