-
-
Notifications
You must be signed in to change notification settings - Fork 862
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Luxon date adapter and formater for variable timezone setting #1661
Comments
Thanks so much for opening an issue! If you'd like to support this project, then please consider sponsoring me |
I see two tasks here. Implementation of luxon based adapterPossibly there is a way to do this without breaking the moment based adapters. Deprecation of moment.jsThis would possibly reduce bundle size and keep the deprecated library out of the project. As I need to remove moment.js from a project, I'd be glad to help with achieving this. |
@lino @dominikbrazdil The current implementation already support |
Oh, I didn't realize that. It's still on my to-do list, though. Thanks for the heads up and the reminder. |
@billyjov 'date-fns' adapter does not work with different timezones than the local one (you need to use date-fns-tz library) |
@dominikbrazdil sure.. there is no support out of the box. so you have to combine |
Is your feature request related to a problem? Please describe
I need to use the calendar in different timezone from user's local one. Currently I am using Moment adapter and formatter as I was not able to implement those using date-fns-tz by myself (tried rewriting all adapter functions to work with converted Dates as described here marnusw/date-fns-tz#67).
But MomentJS is deprecated now and increases the bundle size a lot.
Describe the solution you'd like
In our project we are thinking about using Luxon library (as direct successor of Moment) instead of date-fns-tz and it would be nice if calendar would support this out of the box without need to implement own adapter and formatter.
Describe your use case for implementing this feature
This would make timezone handling in calendar up-to-date with latest libraries and remove the hassle with painful timezone debugging
Additional context
The text was updated successfully, but these errors were encountered: