Move to standard Intl.RelativeTimeFormat

This is now a widely supported web standard, as seen by the compat table here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat

As with everything, Safari is behind so we’re not quite at full support across all browsers yet.

Right now, date-fns simply chooses a format string based on the difference between two dates, then passes it on to format(). We should instead see if we can make use of the built-in Intl.RelativeTimeFormat.

If we switch some day, it’d mean we can delete a lot of locale information and more than likely increase performance, too.

Couple of problems:

• formatRelative wouldn’t use format anymore (probably isn’t a problem anyway)
• Intl.RelativeTimeFormat works on individual units, so we might have to round more to the closest unit if we don’t already (i.e. there would never be a combination like “3 days and 6 hours ago”, it would be “3 days ago”)
• It doesn’t have a concept of something like “Last Sunday” like our current implementation seems to, it would instead be something like “4 days ago”

Happy to try a WIP PR if we have any idea how we’d tackle this.

[kossnocorp]

“Moving” is not an option, but I would love to see a new function that will use the Intl API behind the scenes.

I think intlFormatRelative name is a good option because it suggests that Intl API used and the polyfill is required. Also, in the future, we plan to move I18n to separate packages, and when we do that we can rename intlFormatRelative to formatRelative or create @date-fns/intl.

[AndreiIgna]

The reason I’m using date-fns over other libraries is that it has a small footprint and relies on as many native JS parts as it can. Because of this, I’m also in support of relying on Intl.RelativeTimeFormat for relative date/times. It looks like an obvious advantage of taking advantage of what JS is capable of, instead of duplicating features.