Summary of Time is a construct but it can still break your software

Overview of Time is a construct but it can still break your software

This episode of the Stack Overflow Podcast explores why date and time handling is notoriously difficult in software, and how JavaScript’s new Temporal API aims to fix long-standing problems with Date. Guest Jason Williams, senior software engineer at Bloomberg and creator of the BOA Rust-based JavaScript engine, explains the technical design, the nine-year path to standardization, and what still needs to happen before Temporal is fully woven into the web ecosystem.

Why JavaScript Date Is So Problematic

Jason breaks down the core issue: JavaScript’s built-in Date object was designed for a much simpler era of the web.

Main pain points with Date

• Mutable by default: methods like setDate() modify the original object in place, which often causes accidental bugs.
• Vague APIs: method names such as getDate() and getTime() are not very descriptive.
• Timezone and DST edge cases: daylight saving shifts and timezone conversions can produce surprising results.
• Poor fit for modern apps: what was once “good enough” for small browser scripts became a liability in large enterprise and server-side applications.

Jason’s key point: many Date bugs only show up once applications get complex enough to care about timezones, calendars, and cross-region behavior.

How Libraries Tried to Fill the Gap

Before Temporal, the ecosystem leaned heavily on libraries such as Moment.js, as well as others like Luxon and Date-fns.

What libraries solved

• Better ergonomics than native Date
• Support for formatting, locales, and timezone data
• More intuitive APIs and clearer types

What went wrong

• Bundle size became a major problem, especially for global web apps.
• Libraries often shipped lots of locale and timezone data that many apps didn’t need.
• Even with tree-shaking or custom builds, they could still add 150–200 KB or more.

This pushed the community toward a built-in standard API so browsers could provide the data and functionality directly.

What Temporal Is and How It Works

Temporal is JavaScript’s new built-in date/time API, designed to avoid the common traps of Date.

Core design goals

• Immutable objects
• Clearer type separation
• Timezone-aware operations
• Nanosecond precision
• No external dependency required

Important Temporal types

• Temporal.ZonedDateTime
  A full date-time value tied to a specific timezone. Useful for converting between time zones and handling DST safely.

• Temporal.Instant
  A precise point in time relative to the Unix epoch, stored with nanosecond precision. Best for persistence and transport.

• Temporal.PlainDate / Temporal.PlainTime / Temporal.PlainDateTime
  “Wall clock” values that intentionally ignore time zones. These are ideal when you care about a local date or time without timezone conversion changing it underneath you.

Practical recommendation

Jason recommends storing Instant in databases or back-end systems, then converting it to a timezone-specific display value only when presenting it to a user.

Why Temporal Took About Nine Years

Jason emphasizes that this timeline is unusual even by TC39 standards.

Reasons for the long process

• Huge API surface area: there are many ways to model date/time, and the proposal had to cover them all.
• Extensive debate over API shape: timezone defaults, object types, display formats, and naming all took time to settle.
• Testing burden: Temporal has around 4,500 tests, compared with about 500 for Date.
• Engine size concerns: features like custom calendars and custom time zones were removed to keep JavaScript engines lightweight.
• Standards coordination: serialization had to align with ISO 8601, which required work with IETF.

The takeaway: Temporal is not just a JS feature—it required coordination across language standards, browser engines, and web specs.

Current Status and Next Steps

Temporal has reached Stage 4, meaning TC39 has approved it as part of the JavaScript standard.

Where implementation stands

• V8 support is in place via the Rust-based temporal-rs
• Firefox has shipped support
• Safari support is still in progress, with access available in tech preview
• Work continues to integrate Temporal into the broader web platform

Remaining ecosystem work

• HTML date pickers and form controls
• Structured cloning/serialization support
• High-resolution timestamp APIs
• Library and framework adoption
• Bloomberg’s own internal migration from Date to Temporal

Will Date Go Away?

No—at least not anytime soon.

Why Date will remain

• There is simply too much existing JavaScript code that depends on it.
• The wider web cannot realistically break backward compatibility.
• Smaller, sandboxed runtimes may choose to phase it out, but the public web likely won’t.

Jason’s guidance is essentially: use Temporal for new code, but expect Date to stay around for a long time.

Notable Insight

A particularly interesting detail: the Temporal team used Stack Overflow questions to identify real pain points in the ecosystem. One of the most common questions was effectively, “How do I get an epoch in JavaScript?”—a sign that existing APIs were not intuitive enough.

Key Takeaways

• JavaScript Date has long-standing flaws around mutability, timezones, and ambiguous APIs.
• Temporal is the modern replacement: immutable, clearer, timezone-safe, and nanosecond-precise.
• The proposal took years because it touched a huge surface area and required coordination beyond JavaScript itself.
• Best practice: store Temporal.Instant, display with timezone-aware types.
• Date is not disappearing, but Temporal is the recommended path forward for new software.