All Browsers and Node interop on CLDR for Intl formatting

[snowystinger]

Today, there are many discrepancies in how a JS environment formats dates, numbers, and various other data using the ECMAScript Internationalization API.

For example:

new Intl.DateTimeFormat('en-US',{ dateStyle:'medium', timeStyle: 'medium', timeZone: 'UTC' }).format(0);
// Chrome 'Jan 1, 1970, 12:00:00 AM'
// Safari 'Jan 1, 1970 at 12:00:00 AM'
// Firefox 'Jan 1, 1970, 12:00:00 AM'
// Node 'Jan 1, 1970, 12:00:00 AM'

// Get the whitespace character before AM/PM
['ar-AE', 'bg-BG', 'cs-CZ', 'da-DK',
      'de-DE', 'el-GR', 'en-US', 'es-ES'].map((locale) => {
const formatter = new Intl.DateTimeFormat(locale, { timeStyle: 'long', hour12: true });
const segments = formatter.formatToParts(new Date())
const secondsSegmentIndex = segments.findIndex(segment => segment.type === 'dayPeriod');
          if (secondsSegmentIndex > 0) {
    return segments[secondsSegmentIndex-1].value.charCodeAt(0);
          }
          return 'not used'
})
// Chrome [32, 32, 8239, 8239, 8239, 8239, 8239, 8239]
// Safari [160, 32, 32, 32, 32, 32, 32, 32]
// Firefox [32, 32, 32, 32, 32, 32, 32, 32]
// Node [32, 32, 8239, 8239, 8239, 8239, 8239, 8239]

This is problematic for situations such as React's Server Side Rendering because it will cause a hydration warning, the server rendered content may not match what is rendered on the client. Users can suppress these warnings, though it can be hard when using a 3rd party component that relies on these APIs. Either the user needs to only render the component on the client, or the library needs to expose some way to suppress the warning as well.
Note, other frameworks also have a similar notion of SSR and hydration errors, so this is not limited to React.

This isn't limited to SSR either, it can also affect page layout regardless of the framework. In the example above with the whitespace character before AM/PM, some of those characters are non breaking. This could lead to unexpected text wrapping.

See adobe/react-spectrum#8826 (comment) for more examples and details.

There have been issues in the past as well, see https://bugs.webkit.org/show_bug.cgi?id=218139 which resulted in an update to CLDR.

[sffc]

Yes, server-side-rendered content can't guarantee that it is going to be the same as client-side-rendered content in ECMA-402. It's a known issue, with various solutions proposed, such as a data-driven API for ECMA-402 (#210).

In the meantime, an option to consider is shipping ICU4X on both client and server. It is designed to be efficient in both environments, it guarantees that you'll get the same results, and it gives you more control over what locales are available. The tradeoff is bundle size (since ECMA-402 is "free") and being less consistent with other web sites that use ECMA-402.

[snowystinger]

Thanks for the swift reply and apologies I didn't find that other issue.

I did not know about ICU4X, will add some explorations for that to our library.

[sffc]

I wanted to also point out the Unicode conformance dashboard, where you can visualize and track how different libraries behave. The differences involving non-break spaces and location time zone formats show up there as known issues.

https://unicode-org.github.io/conformance/