https://github.com/you-dont-need/You-Dont-Need-Momentjs might be an option?

Yeah, I guess we should do the "Identify where moment.js is used" task first.
If we're lucky, native functionality could cover our needs.

Moving this to later this year as we would like to use the new date picker implementation from the design system. The date picker is currently not top priority on neither backlogs, so waiting is fine.

cc: @mrosvik

We've added a formatDateLocale function in this pr #1610 which uses the native browser API to format dates. This would probably reduce the efforts of refactoring away from moment.

#602

Just for info, not a strong recommendation by any means: In a previous project the team moved from moment.js to day.js, and that was very easy to do. Exactly the same API, so fixed most of it using Find and replace "momen()" with "dayjs()" (and imports).

In a previous project the team moved from moment.js to day.js, and that was very easy to do

Yeah, also according to the recommendations from the moment team, Day.js seems like the simplest replacement. Are there any good reasons for not just doing that?

I am not sure if this is a show stopper, but the only thing I can think of at the top of my head is i18n and different date formatting for different locales. We support essentially any language in our apps, and would therefore have to preload every known locale (or default to norwegian/english for ones we decide to not support). I guess we might be able to solve this with code splitting and dynamically loading locales, but I think that might be a bit complex.

If we were able to rely on the native browser Intl API instead, we could be able to support any locale, but I am not sure if we can use this API to replace our current usage of moment.