Consider using Intl api #498

Good point, but the Internationalisation API isn't supported in all browsers just yet https://caniuse.com/#feat=internationalization

There are polyfills that can be used on other browsers.

For localization: <script src="https://cdn.polyfill.io/v2/polyfill.js?features=Intl.~locale.zh"></script>

For time zones: https://github.com/yahoo/date-time-format-timezone

I think these things should be done by our libs, not leave to our users.

Ok, it's good to know that. Though users will have to take some action in either case.

With the Intl api, users that want to support older versions of IE need to do:

<script src="https://cdn.polyfill.io/v2/polyfill.js?features=Intl.~locale.zh"></script>

E.g. with dayjs users have to do this to an even greater extent because it must be done for all browser versions:

<script src="https://unpkg.com/dayjs/locale/zh-cn"></script>

Good suggestion.

I just discovered this project and while I was considering to move all my company's projects to this lib I stumbled upon this.

IMHO what's actually killing momentjs is the need to import locales files and the payload burden which this implies. Given the nature of web-apps you cannot know ahead of time (building phase) what locale your users will be needing and importing all of them would result in another momentjs. Leveraging the Intl API provided by the underlying OS/browser is the present and future of date manipulation in JS.

@iamkun would you consider moving to an Intl-first approach with manual locale file importing fallback?

That's all this lib needs to take over in the ecosystem.

I didn't dig into the code to discover how you managed to keep it all under 2kb but hey... GOOD JOB!! 🤟🏻

@damianobarbati you could import locale files dynamically based on user's OS.

@xxyuk sure, I can async-import anything and work-around whatever in a web application. But the less code, the less bugs. And browser can do the heavy lift, so why carrying this burden? :)

date-fns does exactly what @benmccann suggested:

Dependency free IANA time zone support is implemented via the Intl API to keep actual time zone data out of code bundles. Modern browsers all support the necessary features, and for those that don't a polyfill can be used.

@issuehunt has funded $200.00 to this issue.

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

Intl is a nice choice for timezone plugin

the Intl api will output "11th of may" semantically in russian while it remains as a single word and a number, therefore conforming to the order of format that asks for month's day after the month would be incorrect in that language. I'm writing this feature so that it will default to locale file if it's provided, but use and accept intl options otherwise, like localized numbering/calendars while only listening to how abbreviated you want the string to be.

It will also default to the previous behavior with respect to the ordering of date with default locale of en, ignoring intl options.

It is 2020, Intl api is supported by most browser (caniuse) except Opera Mini, QQBrowser and Kalios browser. 95% of the users.

I was looking into this article and Dayjs and Luxon are clearly the winner there. My experience with Luxon and Intl was very good, I'm sad that Day.js does not support it.

We're trying to find a simpler way to detect and correct daylight savings related changes, in liu of roling with just the simple solution and rewarding that with the bounty.

Update: Day.js Time Zone Plugin with Intl API

https://day.js.org/docs/en/timezone/timezone

Update: Day.js Time Zone Plugin with Intl API

https://day.js.org/docs/en/timezone/timezone

Hi @iamkun the timezone plugin works great, however the localizedFormat plugin still depends on loading the locale files