Switch from date-fns to the browser's Intl

[dgreene1]

Is your feature request related to a problem? Please describe. Yes, the problem is that if I want to support internationalization for multiple countries, I can't support countries that date-fns doesn't support. And at my company, that means that 30 of the countries we want to support we can't. (Note: the support for many countries in the English language is severely limited in date-fns and the work to contribute those would be massively cost prohibitive).

Describe the solution you'd like Instead of relying on date-fns to format dates, we would use Intl since it's supported in all major browser versions now.

Describe alternatives you've considered As mentioned, we considered adding our needed formatters to date-fns but it would take months or years to add them all. And then to keep them up to date would be a massive undertaking.

Additional context You'll notice that Saudia Arabia and Greece do not exist in the english language here: https://github.com/date-fns/date-fns/blob/16c529508a323d78f70b91209ebf043f3c09671d/src/locale/index.ts#L29

[Zarthus]

Hi,

I'm personally completely open to this switch (I'd love to get rid of date-fns myself), currently our engineering focus does not mark this as priority however, but we'd be happy to review a MR that makes this change happen.

[dgreene1]

Thank you. Since this would be an extremely large undertaking for any contributor, I’d like to get confirmation that this PR would be accepted and that it would be released within short order after its approval. Like if it’s considers a major release in the semver, would @martijnrusschen and others have to wait until other breaking change PRs came in?

btw, @Zarthus, if it’s not a priority, how are you and others handling countries that date-fns doesn’t support?

And I apologize but I am asking Scheduler questions. As an open source maintainer I understand how frustrating it is to get that question. But as someone who needs to hit a deadline for our own customer, it’s important to know if we’ll need to use a date-fns workaround to meet the immediate goal and then consider coming back to this Intl replacement issue after our deadline.

tl;dr: could a major release go out quickly or would it need to wait for something?

[Zarthus]

@martijnrusschen I think we can make this happen, is this something you're okay with supporting as well? Was there a reason we need data-fns or purely convienience?

From my POV, as long as there are no major regressions getting rid of an external dependency to use technology built into JS nowadays seems like a win to me.

I agree it's no small undertaking, we're working on a few of those ourselves too in this repo hence we cannot commit to this at the moment (doing it ourselves)

I'm not sure how tight your deadline is? But Im happy to personally review Mrs and we also recently enabled PullRequest so reviews should be timely. But if it's hours or days, you're better off with a workaround, most likely, or doing only a partial conversion (only converting the things that use i18n), we don't want to rush something into the source code.

An alternative suggestion is to contribute those locales to date-fns, which might also work.

Not sure if we have any workarounds in place to handle locales we do not support, but better i18n is a win to me.

[Zarthus]

You might be able to get away with refactoring only a portion - localization seems to mostly be used in format* and InLocale functions - it's not a super comprehensive look though

Would significantly reduce required code changes and enable more locales (any the browser supports; which is always going to be one the user likes using)

[dgreene1]

Just an update that we're struggling to find capacity within our team for us to make this change. Maybe we're find the time, maybe we won't.

So I would encourage someone else to take on this work.

I think it's motivation enough to start using data that is far more up-to-date (like Intl is), but I think this is valuable enough simply because it can reduce bloat. But it's not moving the ticker for our product management at this time since we have a workaround by splitting the input from the dropdown and then using our own formatter (Intl) on the raw string that comes from the change events.

[yuki0410-dev]

I am now interested in this issue. (I would like to respond to it if I have time.)

However, I am concerned that Intl does not allow specifying strings in formats such as yyyyy-MM-dd, which would be a huge burden on the user.

Instead, we would like to use @formkit/tempo, which is an Intl wrapper. Also, I would be happy to replace only the format and other locale-related parts at first, and then, eventually, completely replace @formkit/tempo from date-fns. (There are a few missing methods, so I guess I'll have to make those myself with reference to date-fns).

[yuki0410-dev]

https://github.com/tc39/ecma402/issues/374