Free tools Windows power users keep installed
One-click scans. No signup required.
JavaScript’s Temporal API gives date-and-time values distinct types so code can express whether it means a calendar date, a wall-clock time, an exact timestamp, or a date and time in a named time zone. That makes many common operations easier to reason about than with the legacy Date API—but developers still need to choose the right type, define how to resolve time-zone transitions, and check whether their target runtimes support Temporal.
What Temporal changes in JavaScript
Temporal is a built-in ECMAScript date-and-time API designed around separate, immutable types. Rather than treating every value as a timestamp or a loosely interpreted date string, it distinguishes calendar dates, times of day, local date-times, exact instants, and time-zone-aware date-times. It also includes types for year-month and month-day values, plus durations. See the TC39 Temporal proposal and the official Temporal documentation.
This model addresses common limitations of the legacy Date API, including mutable objects and the difficulty of representing date-only or time-only values without implying a time zone. Temporal does not make every date-and-time problem automatic: the application must still determine what a value means, which calendar rules apply, how to interpret local times around time-zone changes, and which input and output formats it accepts.
Which Temporal type should you use?
Choose a type according to the meaning of the data, not just its shape. Temporal’s “Plain” types have no associated time zone, so they do not by themselves identify an exact moment on the timeline.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
| What the value means | Likely type | Example and guidance |
|---|---|---|
| A calendar date without a time or time zone | Temporal.PlainDate |
A birthday or holiday when the intended value is the date itself, not an instant. |
| A time of day without a date or time zone | Temporal.PlainTime |
A store’s opening time, such as 09:00, when no particular date is implied. |
| A local date and time without an associated time zone | Temporal.PlainDateTime |
An unzoned appointment value. Do not silently interpret it as UTC or as the machine’s local time. |
| A unique point on the timeline | Temporal.Instant |
A timestamp used to record when an event occurred or to order events. |
| A date and wall-clock time interpreted in a named time zone | Temporal.ZonedDateTime |
A civil appointment whose intended time depends on a zone such as one used by a particular city or region. |
Moving between an unzoned local value and an exact or zoned value can require a decision: a local time may not exist or may occur twice during a time-zone transition. Temporal provides disambiguation options; select and document a policy when that choice affects users or records. The official documentation describes the types and conversions.
Calendar days are not always fixed elapsed time
A date-based instruction such as “the same local time tomorrow” is not always equivalent to adding a fixed number of elapsed hours. When a time zone changes its offset, a calendar day can span more or less than 24 hours. Temporal makes this distinction visible: calendar arithmetic on a zoned value expresses a civil-time operation, while adding a fixed elapsed duration expresses movement along the timeline.
Rank #2
Time-zone transitions also create missing and repeated local times. If clocks move forward, some wall-clock times do not occur; if clocks move back, some occur twice. When converting a local date-time into a zoned value, decide how the application should handle those cases rather than relying on an unstated assumption. Use a zone-aware value when the zone is part of the intended meaning; use an instant when the value must identify one exact point in time.
Common ways to get the current date or a timestamp
The Temporal cookbook shows separate methods for local calendar values and exact timestamps. For today’s local ISO calendar date, use Temporal.Now.plainDateISO(). When both the local date and wall-clock time are needed, use Temporal.Now.plainDateTimeISO(). For an exact timestamp, use Temporal.Now.instant(). The cookbook also shows reading epochMilliseconds from an instant and deriving seconds from that value; see the Temporal Cookbook.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →These methods answer different questions. A local date is suitable when the program needs a calendar day in its current local context; an instant is suitable when it needs a unique timestamp. Do not substitute one for the other merely because both can be represented with numbers or strings.
Parsing: ISO-looking does not mean accepted
Temporal uses specified string formats, but “ISO 8601” is not a guarantee that every ISO form is accepted by every Temporal operation. The official string documentation says that ISO year-week-day strings such as 2020-W13-5 are not parsed by the initial API. If an application receives that form, parse or transform it with an explicitly defined approach instead of assuming Temporal accepts it directly. See Temporal string parsing.
Rank #4
The proposal describes interoperability in the context of standards including ISO 8601, RFC 3339, RFC 9557, and iCalendar/RFC 5545. That does not mean every extension has identical support in every Temporal method; validate the exact formats your application consumes and produces. The proposal provides the standards context.
Standard status and runtime support
The TC39 proposal page is labeled “Stage 4 Draft / July 27, 2026.” The ECMAScript 2026 specification explains that yearly snapshots include completed Stage 4 proposals. This standards status is separate from whether a particular browser or server runtime version implements Temporal.
MDN currently labels its Temporal reference “Limited availability” and says Temporal is not Baseline because it does not work in some widely used browsers. Check support for the exact browser and server-runtime versions your project targets; there is not a universal version-by-version support claim here. If a required environment lacks native support, a polyfill may be an option. Check current package guidance and compatibility before choosing one.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to approach a migration from Date
Do not replace every Date mechanically. First classify what each value means, then choose the Temporal type that preserves that meaning. The cookbook documents converting a legacy Date to an instant or to a zoned value representing the same instant.
Quick Recap
- Classify the existing data. Identify whether each field is a date only, a local wall-clock value, an exact timestamp, or civil time tied to a named zone.
- Choose a matching type. Use a Plain type for an unzoned calendar or wall-clock value,
Temporal.Instantfor an exact point in time, andTemporal.ZonedDateTimewhen a named zone is part of the data. - Define zone and ambiguity behavior. Specify the intended time zone and the policy for missing or repeated local times wherever conversion requires a resolution.
- Check actual inputs and outputs. Test the string formats the application really receives and emits, including formats Temporal does not parse directly.
- Verify deployment support. Check the project’s target runtime versions and decide whether native support is sufficient or a compatible polyfill is needed.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
