MagicMirrorOrg
[Change Request] Migrate away from Date and Moment in favor of something that is actively supported and easy to use
What problem do you want to solve with this change?
Moment library is in maintenance mode
What do you think is the correct solution?
Migrate MagicMirror to another Datetime library that is lightweight, usable and supports timezone calculations well.
Participation
- [ ] I am willing to submit a pull request for this change.
Additional comments
Javascript Date is not very usable especially with calculations and timezones and Moment (and Moment Timezone) are currently in maintenance mode. Luxon is the succesor of Moment that uses the Intl API. There are probably other options aswell which we can discuss here.
Since Moment.js is still being maintained, we're in no rush, but yes, it makes sense to switch sooner or later. We have already touched this topic in other places (e.g. in the forum), but have not discussed it in depth.
To have a good overview, I've created a table with alternatives and possible decision criteria.
| Criteria | Moment.js | Day.js | date-fns | Luxon | Temporal API |
|---|---|---|---|---|---|
| Migration from Moment.js | N/A | ⭐⭐⭐⭐⭐ Very Easy |
⭐⭐ Complex |
⭐⭐⭐ Medium |
⭐⭐ Complex |
| Native in node and browser | ❌ | ❌ | ❌ | ❌ | ❌ now with polyfill ✅ in the future |
| Immutability | ❌ | ✅ | ✅ | ✅ | ✅ |
| Time Zone Support | ⭐⭐⭐ Good |
⭐⭐⭐ Good (via Plugin) |
⭐⭐⭐ Good |
⭐⭐⭐⭐⭐ Excellent |
⭐⭐⭐⭐⭐ Excellent |
| Status | ❌ Legacy |
✅ Active & Stable |
✅ Active & Stable |
✅ Active & Stable |
➖ Active, but as polyfill |
| Ideal for... | Existing legacy systems | Quick migrations, small apps | Performance-critical apps | Complex apps with time zones | Future-proof projects (with polyfill) |
| Open Issue Ratio1 | ✅ 6% open: 238 total: 4147 |
❌ 52% open: 906 total: 1753 |
❌ 31% open: 619 total: 1982 |
✅ 14% open: 156 total: 1128 |
✅ 3% open: 36 total: 1380 |
| Last Commit2 | ❌ 02/2024 | ✅ 05/2025 | ❌ 09/2024 | ✅ 04/2025 | ✅ 06/2025 |
Does anyone miss any criteria? Would you rate some things differently?
I'm currently in favour of the Temporal API (especially because it will be built in natively and it has excellent time zone support), either now (with a polyfill) or later with the native implementation. But maybe I'm missing something that speaks against it.
When we decide to change, we should inform the community well, as there are some 3rd party modules that (contrary to best practice) use Moment.js from the core and do not install them themselves. This is not a blocker, I think, but we should keep it in mind.
1 An Open Issue Ratio above 25 % is considered to high. 2 A Last Commit more than six months ago is considered too high.
From this comparison dayjs looks like a good alternative, but what I'm missing here is the amount of issues currently open for each project and what kind of issues there are. If you look at issues like this: https://github.com/iamkun/dayjs/issues/2881 I would think twice before proceeding with dayjs right now, which has over 900 open issues as of this moment, and less than 900 closed issues. Luxon for example has only 150 open issues and over 900 closed issues which also look well maintained with fast response times and labelling.
When we decide to change, we should inform the community well, as there are some 3rd party modules that (contrary to best practice) use Moment.js from the core and do not install them themselves. This is not a blocker, I think, but we should keep it in mind.
this is independent of the choice here, we had the same problem already in the past (e.g. with request). It will produce a lot of support but we have no choice in the long term.
I have no favorite and I'm to far away from the nodejs/javascript stuff for deciding this (only experience is using date-fns in my modules without problems).
what I'm missing here is the amount of issues currently open for each project
For candidates at the same level, we should always consider how well the projects are maintained.
Personaly, i chose Day.js about a year ago.
Advantages: syntax is very similar to moment
what I'm missing here is the amount of issues currently open for each project and what kind of issues there are.
I have just added a new row: "Open Issue Ratio" — it's easy to calculate, but it doesn't tell us anything about issue types or response times. However, a ratio above 25% still seems too high to me, so I added a negative symbol.
Are there any simple ways to get comparable numbers for each project on the issue types?
If you look at issues like this: https://github.com/iamkun/dayjs/issues/2881 I would think twice before proceeding with dayjs right now
Yes, that issue looks like a blocker for Day.js.
we should always consider how well the projects are maintained.
Yes. But how can we get comparable numbers for that? Basically all seem to be active, as the last commits in the respective main branch were almost all within the last 6 months.
Personaly, i chose Day.js about a year ago. Advantages: syntax is very similar to moment
Yes, that's a big plus, which is why I gave it five stars in the 'Migration from Moment.js' category. However, the 'Time Zone Support', 'Open Issue Ratio' and the issue @plebcity mentioned are standing against Day.js.
At the end of the day, we need someone willing to carry out the migration. I would not be able to create a PR myself for now. Who would be willing to create a PR for which option(s)? If no one wants to do it, we don't need a final decision yet. And waiting until the Temporal API is integrated into node and the browsers would not be a bad option I think.
@rejas and @sdetweil, what do you think?
I think it's good to leave the issue open, because at some point in the future we will switch.
And I think it's clear that switching to any alternative would be an improvement on the current situation. Even though I would prefer Temporal, I would support a PR to any alternative. That's why I added the label “PR Welcome.”
the stale issue monitor doesn't have any mechanism to skip certain issues so we will have to update them
And I think it's clear that switching to any alternative would be an improvement on the current situation.
Why is moment a problem? It seems to do what it needs to, and if I understand maintenance mode correctly, we'll continue to get security patches, just no new features. My plan for my modules is to switch from moment when Temporal is available, but I have no strong desire to switch to something else in the interim...but am now wondering if I should.
the stale issue monitor doesn't have any mechanism to skip certain issues
It does 🙂 It ignores issues with certain labels: https://github.com/MagicMirrorOrg/MagicMirror/blob/62b0f7f26ec9531aafa91c2020c452ae2ae9d307/.github/workflows/stale.yaml#L22
Why is moment a problem?
I wouldn't use the word “problem”. Alternatives just would be a little better, but the cost/benefit ratio doesn't favour an interim switch unless there's a critical issue with moment (which there isn't).
But should we hold out against a well-prepared PR for an interim solution? Since no one has yet expressed an interest in pursuing a PR, we do not actually need to answer this question.
I favor a pragmatic approach and be open for a PR that does the easy migration to day.js
All other migrations seem more expensive for now...
In reading the day.js website, it looks like support for locales is on demand. Wouldn't that make it hard for module developers to code for allowing users to select a locale based on their config.js?
Like I said earlier, I wouldn't migrate to day.js because the many issues on Github that aren't resolved. I'd rather someone spent more time migrating to something that is actually properly supported than shortcutting it with day.js since it uses the same syntax.
Also I agree with keeping this issue open so someone can see the discussion here before opening a PR to migrate it and also it's a good place to have all datetime discussions apart from issues reported by users.
Does anyone have a sense of the timeline for Temporal? moment.js just works (for now).
Does anyone have a sense of the timeline for Temporal? moment.js just works (for now).
To my knowledge, there is no official timeline. I would expect it (native support in modern browsers and node.js) to happen sometime in 2026.