To have a better understanding of what operations you are trying to do. I can't answer your question specifically because it depends a lot on use case and what date/time standards you want to use.
To expand on this a little, there are operations that have slightly ambiguous meanings/can end up with different answers depending on your assumptions.
e.g. If today is the 30th of January 2024. What is the date in 1 months time?
Should it be the 29th of February? (as the 30th doesn't exist). The 28th? (the penultimate day of the month, like the 30th of Jan). The 1st of March (a 'standard' month should be considered 30 days, so 30 days from now).
To be honest, use a library where someone else figured out the ambiguities and accounted for the edge cases. Good starting point: https://moment.github.io/luxon/#/math
Date-fns is fine for simpler use cases but Luxon is a lot more complete, especially where it comes to time zones.
This is not the kind of thing you just want to blindly hack your way through without a really thorough understanding of how different cultures/locales/governments handle dates and times.
If you have to do math across daylight savings time boundaries that change over time (because governments and regulations change), converted to two or more time zones (which again have their own separate DST rules), and possibly span some 30 or 45 minute time zones (they exist!) this will quickly get out of hand and unreadable. Not just unreadable, but incredibly difficult to reason about.
It gets even worse when the backend stores only the offset (as in the ISO time, like T23:00:00+08:00) because then you lose the original time zone and can't be sure whether it came from a DST zone or another country in the same zone (but only during part of the year).
When you cross DST switchovers, for example, you may magically gain or lose an hour. A naive milliseconds calculation will miss that. It gets worse because DST in a country isn't a static thing either, but will change with the laws over time. So over decades, you need to have several lookup tables.
And people are ambiguous. Is January 31 plus 1 month the end of February or the beginning of March? What about during a leap year?
And a "day" isn't necessarily 24 hours (because of DST, again). Humans doing day math across those boundaries will just ignore (or really, never think about) the missing or gained hours, but computers have to explicitly account for it.
Then once you throw in different time zones it gets even crazier, especially for the half hour and 45 minute zones.
It's okay to store datetimes in epoch milliseconds (ideally with a separate field for the time zone, not just offset, which holds less information). But you can't easily/correctly do math on that without more specific instructions and cultural/locale adjustments.
