Date arithmetic and time zones
Temporal
Chrome144
Edge144
Firefox139
Safari-
Features it needs
- TemporalLimited availability
These libraries exist because Date cannot do the job: it has no concept of a time zone beyond the host's, and adding a day across a daylight saving boundary gives the wrong answer. Temporal is the replacement, with ZonedDateTime carrying an IANA zone and arithmetic that respects it. It is not in every engine yet, so this is a plan rather than a deletion, and the honest move today is the official polyfill.
When this applies
Doing date arithmetic or working with named time zones.
The native approach
const meeting = Temporal.ZonedDateTime.from(
"2026-03-08T01:30:00-05:00[America/New_York]",
);
// Adds a calendar day, not 24 hours, so the DST change is handled.
meeting.add({ days: 1 }).toString();When the dependency is still right
An answer that always says "the platform covers it" is worse than no answer. These are the cases where this one does not hold.
- You ship to Safari, or to any engine below Chrome 144 or Firefox 139. Temporal is not available everywhere yet, so today this means adding @js-temporal/polyfill rather than removing a dependency, and that polyfill is larger than most of the libraries it would replace.
- You only format dates for display. Intl.DateTimeFormat already does that everywhere, and the date-format rule covers it. Temporal is for the arithmetic.
- You parse loose or non-ISO input. Temporal is deliberately strict and throws on anything ambiguous, which is the opposite of what moment was liked for.
- You depend on moment-timezone's bundled zone database at a pinned version, for example to reproduce a historical calculation. Temporal reads the zone data the engine ships, which moves under you.
- The codebase is on moment and the migration is the work. Two date libraries in one bundle is worse than one, so a partial migration costs more than either end state.
Signs it was hand-rolled
No package is involved in any of these, so nothing would match in a package.json. If the code looks like one of them, this rule applies anyway, and the conditions above still decide.
- a date rebuilt through UTC offsets with getTimezoneOffset, to move a timestamp into another zone
- adding 86400000 milliseconds to a timestamp to mean tomorrow, which is an hour out on the two days a year the offset changes