Back to all features
Open for signals
JavaScript
Temporal
The Temporal API allows you to work with dates, times, time zones, and durations. It is more powerful than the Date API.
Modern Web Guidance
How Modern Web Guidance uses this feature
Employs the modern Temporal API (Temporal.Now.zonedDateTimeISO(), Temporal.Duration, Temporal.PlainDate) for accurate, timezone-aware date and time arithmetic without legacy Date bugs.
Recommended fallback strategy
For browsers lacking native support, load the @js-temporal/polyfill conditionally after feature detection (!window.Temporal).
Related use cases
-
Calculating event differentials with Temporal JavaScript(opens in new tab)
-
Capturing location-agnostic data with Temporal JavaScript(opens in new tab)
-
Coordinating global events with Temporal JavaScript(opens in new tab)
-
Formatting human-readable durations with Temporal JavaScript(opens in new tab)
Show 5 more related use cases Show fewer use cases
-
Managing recurring intervals with Temporal JavaScript(opens in new tab)
-
Modeling partial time concepts with Temporal JavaScript(opens in new tab)
-
Stabilize reactive state with Temporal JavaScript(opens in new tab)
-
Supporting global calendar systems with Temporal JavaScript(opens in new tab)
-
Sequencing distributed events Performance(opens in new tab)
Community use cases (6)
Community signal summary
Developers strongly advocate for native
temporalsupport to eliminate the architectural limitations and comparison bugs of the legacy JavaScriptDateobject [1][4]. Primary use cases include cleanly managing timezone-agnostic plain dates and datetimes to simplify application code and eliminate external dependencies [1][6], handling partial date structures like isolated times and year-month combinations [1][3], and executing complex timezone arithmetic withTemporal.ZonedDateTimeand IANA timezone identifiers [2][4]. Applications span nationwide platforms handling client-set schedules [6], multi-timezone interfaces [2], and specialized astronomical software requiring topographic observer corrections and robust local timezone calculations [4].In the meantime, developers must bundle third-party libraries like
date-fnsanddate-fns-tz[6] or load polyfills with custom overflow logic [2][3], while maintaining proprietary helper suites to prevent server and client timezone drift [6]. Teams are forced to write custom string parsers [3] or manually normalize unused fields on standardDateinstances to prevent comparison errors [1]. Becausetemporallacks support on iOS and Safari [3][4], teams face compounding maintenance burdens across client dependencies, with some developers choosing to leave functionality unsupported on Safari rather than managing the overhead of client-side polyfills [4].Generated by AI from community comments and may contain inaccuracies. Read the comments below for full developer context.
This summary covers all 6 comments, is up to date, and was last updated on September 11, 2026.
What I want to do with this feature
I want to handle partial date and time data (only time or only day, or dates without timezone).
What I'm having to do in the meantime
In the meantime I use JavaScript Date objects to represent such data, but I have to be careful to set the value of unused fields for comparisons to work as expected (forgetting to do so can lead to unexpected problems).
What I want to do with this feature
What I'm having to do in the meantime
im using a polyfill and some overflow code to achive what i want.
What I want to do with this feature
Easily handle dates, times, months (with years but not dates) in a straightforward manner, without writing string parsers and normaliser functions. The localisation support and timezone handling is an added bonus.
What I'm having to do in the meantime
I have to use a polyfill if there's any chance my users use iOS or Safari.
What I want to do with this feature
Let's see I am using temporal for zdt (ZonedDateTime) and IANA time zone names and time zone support in ways that Date() never could
I'm using temporal inside an astronomical/celestial app with topographic observer corrections, so strong local time zone support is very much a hard requirement.
What I'm having to do in the meantime
BTW, this just doesn't work on iOS right now, and I have no intention of backfilling or polyfilling or anything else.
@anthonymhumphreys I took the liberty to apply the template to your comment. I did not change the content of your comment, I only added the headings from the template. Thank you for your comment.
What I want to do with this feature
I work on an app used by folks across the country with a lot of client-set dates and datetimes. These date(time)s have no need to be timezone-aware, so using Temporal (without introducing a polyfill) will allow us to simplify all of our date handling and remove dependencies.
Workarounds currently used
Use
date-fns/date-fns-tzfor date manipulation and timezone handling (despite formatting all going throughIntl.DateTimeFormat). We also have our own robust suite of helpers to ensure timezones are displayed consistently regardless of server/client drift.