[Change Request] Migrate away from Date and Moment in favor of something that is actively supported and easy to use

[plebcity]

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.

[KristjanESPERANTO]

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.

¹ An Open Issue Ratio above 25 % is considered to high.
² A Last Commit more than six months ago is considered too high.

[plebcity]

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: iamkun/dayjs#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.

[khassel]

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.

[bugsounet]

Personaly, i chose Day.js about a year ago.

Advantages: syntax is very similar to moment

[KristjanESPERANTO]

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: iamkun/dayjs#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?

[KristjanESPERANTO]

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.”

[sdetweil]

the stale issue monitor doesn't have any mechanism to skip certain issues
so we will have to update them

[dathbe]

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.

[KristjanESPERANTO]

the stale issue monitor doesn't have any mechanism to skip certain issues

It does 🙂 It ignores issues with certain labels:

MagicMirror/.github/workflows/stale.yaml

Line 22 in 62b0f7f

exempt-issue-labels: "pinned,security,under investigation,pr welcome,ready (coming with next release)"

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.