Open benmccann opened 5 years ago
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? :)
@issuehunt has funded $200.00 to this issue.
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.
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
Update: Day.js Time Zone Plugin with
Intl
API
Hi @iamkun the timezone plugin works great, however the localizedFormat plugin still depends on loading the locale files
Any updates?
Just to mention, intl isn't updated by browsers too quickly, that's the difference between moment-tz and Intl
Any updates?
I really like the way Luxon does localization and time zone support by using Intl.DateTimeFormat
For time zones, it allows the user to specify any time zone without any extra files to download compared to solutions for other libraries that are quite large. See their timezone docs and code for more details. This could be a possible method of implementing https://github.com/iamkun/dayjs/issues/323, https://github.com/iamkun/dayjs/issues/249, https://github.com/iamkun/dayjs/issues/46
For localization, it's far easier to maintain because you do not need to create or maintain any translations on your side. This could fix several issues such as https://github.com/iamkun/dayjs/issues/416, https://github.com/iamkun/dayjs/issues/415, and https://github.com/iamkun/dayjs/issues/171. It's also easier for users because they don't need any extra files and everything works out-of-the-box. See their Intl docs and code for more details
Would there be any interest in this approach?