Temporal: JavaScript time handling is finally getting sane

2026-03-12 • inspired by today’s Hacker News discussion on Temporal’s long path into JavaScript

JavaScript’s old Date API mixed too many concepts in one type: absolute instants, local wall-clock values, calendar representation, parsing quirks, and timezone assumptions. It worked for demos and quietly broke production systems around daylight saving transitions, offset math, and cross-region scheduling.

Why Temporal matters

• Explicit types: Instant, PlainDate, ZonedDateTime, and friends model different time concepts directly.
• No hidden timezone jumps: conversion requires an explicit zone, reducing accidental local-time bugs.
• Predictable arithmetic: date math distinguishes calendar operations (months/days) from exact durations (seconds/nanos).

The practical architecture shift

A robust rule of thumb: store and exchange Instant, render with ZonedDateTime at the boundary, and keep business rules in PlainDate/PlainTime where human calendar semantics matter.

server DB: Instant (UTC)
user locale: TimeZone + Calendar
UI render: ZonedDateTime
business rule: PlainDate (e.g., billing day 1)

This separation feels nerdy, but it makes failures less magical. Temporal doesn’t remove complexity from time — nothing can — it makes complexity visible where it belongs.

Nerdy takeaway

Time bugs are usually type-system bugs wearing a calendar costume. Temporal is basically a late but very welcome correction: model time with semantic types first, formatting second.