Replace legacy Date with Temporal: PlainDate, ZonedDateTime, Instant, Duration, and timezone-aware arithmetic.
0 / 5 completed
1 / 5
What problem does the TC39 Temporal API solve that the legacy Date object cannot?
Temporal: the legacy Date object is mutable, conflates calendar and timezone, uses 0-indexed months, and has confusing methods. Temporal introduces distinct, immutable types for each use case: wall-clock time, absolute instants, calendar dates, and timezone-aware datetimes.
2 / 5
What is the difference between Temporal.PlainDate and Temporal.ZonedDateTime?
PlainDate vs ZonedDateTime: use PlainDate for birthdays, holidays — dates that don't shift across timezones. Use ZonedDateTime for scheduling meetings where DST transitions must be respected. Adding a day to a ZonedDateTime correctly handles the 23-hour or 25-hour day during DST changes.
3 / 5
What is Temporal.Instant and when should you use it?
Temporal.Instant: represents an exact moment in time as nanoseconds since the Unix epoch. Unlike ZonedDateTime it has no calendar or timezone context. Use it for database timestamps, audit logs, or performance measurements where only the relative ordering and difference between moments matters.
4 / 5
What does Temporal.Duration represent and how is it different from a millisecond count?
Temporal.Duration: "1 month" is not a fixed number of seconds — it depends on which month. Temporal.Duration.from({ months: 1 }) added to January 31 gives February 28/29, correctly handling variable-length months. A raw millisecond count cannot represent this.
5 / 5
How does Temporal.Now.zonedDateTimeISO() differ from new Date()?
Temporal.Now: the result is immutable and carries the IANA timezone identifier (e.g. "Europe/London"). Arithmetic respects DST rules automatically. You can call .withTimeZone("America/New_York") to convert, and .toPlainDate() to drop time — operations that are error-prone with legacy Date.