On May 13, 2026, Publickey published Temporal Date and Time Processing Replacing Date in Node.js Is Enabled by Default; Temporal Is Now Available in Chrome, Edge, Firefox, and Node.js. The Temporal API is the fundamental successor specification to JavaScript's Date object, and it has finally become standard by default across both runtimes and browsers.
In custom development environments, bugs involving "timezone offsets, leap seconds, DST transitions, and Date comparison pitfalls" surface constantly. These are structural flaws of JavaScript's Date that cannot be fundamentally solved by patching on moment.js, Day.js, or date-fns. Enabling the Temporal API by default marks a turning point that makes completely banishing Date from business code a practical option.
Why Date and moment.js have reached their limits
| Challenge | State of Date / moment.js |
|---|---|
| Timezone handling | Behaviors differ between server and client |
| Immutability | Mutable, causing side effects |
| Leap seconds / DST | Unhandled by most libraries |
| TypeScript compatibility | Degrades to unknown / any |
| Bundle size | moment.js is 290 KB (70 KB gzipped) |
| Maintenance | moment.js is practically frozen |
These issues are often deferred under the assumption that "we'll fix them someday," only to materialize as operational incidents such as "payment settlement dates drifting by a day" or "invoice month-end discrepancies." Temporal's specification eliminates these issues at the architectural design level.
Five key strengths of the Temporal API
Strength 1: Clear separation of "Instant" and "ZonedDateTime"
It treats "absolute coordinates in time" (Instant) and "time as perceived by humans" (ZonedDateTime) as distinct types. Bugs caused by "mixing server time with display time" are structurally prevented from occurring.
Strength 2: Immutable objects
The mutable setHours and setDate methods of Date have been a breeding ground for side-effect bugs. Temporal is completely immutable, allowing time to be manipulated in a functional manner.
Strength 3: Treating timezone IDs as first-class citizens
It preserves IANA time zone IDs like Asia/Tokyo and America/New_York as types, while specifying DST calculations right down to the specification level.
Strength 4: Operations on durations and periods
Business calendar calculations like "the last business day three months from now" can be expressed using standard APIs. This is the date-and-time counterpart to the "expressing business logic through types" trend covered in the TypeScript 6 Migration Guide.
Strength 5: No additional libraries needed
Because Temporal is a runtime and browser standard, it introduces zero external dependencies. This directly contributes to smaller bundle sizes and a reduced security audit surface.
Four modernization phases built in custom development
Phase 1: Date processing inventory (2 weeks)
Using ts-morph and AST analysis, we identify every usage of new Date, moment(, dayjs(, and date-fns, then classify the business impact into three levels.
Phase 2: Introducing the wrapper layer (3 weeks)
Because rewriting the entire application logic to Temporal at once is unrealistic, first introduce a wrapper layer that converts to Temporal at domain boundaries. Initially modify only two boundaries: DB → Temporal and Temporal → API responses.
Phase 3: Domain layer migration to Temporal (6–10 weeks)
Migrate incrementally by business domain. Execute "domain-level reviews and regression testing" in order across billing → revenue → inventory → attendance. Use property-based testing (such as fast-check) alongside regression suites.
Phase 4: Removal of moment.js, Day.js, and Date (3 weeks)
In the final phase, prohibit new Date and moment( using ESLint's no-restricted-syntax, and remove the dependencies.
Standard technology stack set for custom development
| Layer | Recommendation | Alternative |
|---|---|---|
| Time types | Temporal API (standard) | luxon |
| DB type conversion | Temporal ↔ ISO 8601 strings | Temporal ↔ Date wrappers |
| API schema | Zod + custom Temporal types | tRPC / OpenAPI |
| Testing | fast-check + vitest | jest + sinon |
| Static analysis | ESLint no-restricted-globals | typescript-eslint |
| ORM integration | Custom adapter for Drizzle | Custom scalar for Prisma |
| i18n | Intl.DateTimeFormat (standard) | date-fns/locale |
In particular, ensuring type safety at API boundaries using Zod + custom Temporal types allows frontend-backend time-drift bugs to be detected at compile time.
Which projects it fits best
| Suited projects | Benefit |
|---|---|
| Settlement / Billing / Payroll | Structural resolution of month-end and cutoff discrepancies |
| Reservations / Shift scheduling | Precision across DST and timezone boundaries |
| International SaaS | Standardization of multilingual i18n |
| Log aggregation and analytics | Higher analytical precision by unifying on Instant |
| Audit logs | Time consistency in tampering detection |
Five clauses to include in custom development contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target module scope | Domains targeted for migration | Responsibility for out-of-scope modules |
| Compatibility API maintenance period | Retention duration for legacy APIs | Operational burden during migration |
| Regression testing criteria | Pass rates and thresholds | Acceptable tolerance for business impact |
| Warranty for TZ and DST bugs | Remediation scope for existing bugs | Delta between expected and current states |
| ESLint guards | Rules preventing legacy API resurgence | Code review structure |
Four common pitfalls
Pitfall 1: Attempting an all-at-once rewrite
Rewriting business domains concurrently causes the regression testing scope to explode. Designing the project to progress strictly one domain at a time is mandatory.
Pitfall 2: Neglecting database types
Passing data stored as TIMESTAMP WITHOUT TIME ZONE into Temporal leads to incidents where values turn out to be JST rather than UTC. Conducting a database type audit in Phase 1 is mandatory.
Pitfall 3: Migrating the frontend while leaving Date on the backend
If API responses provide Date-derived strings, Temporal may be unable to reconstruct timezone information. Simultaneous frontend and backend migration is essential.
Pitfall 4: Failing to completely eliminate legacy APIs
Keeping legacy APIs under the assumption that "we might need to revert" causes Date to creep back into new code within three months. Always establish ESLint guards and CI checks.
Summary — From "Date hell" to expressing date and time as business types
Enabling the Temporal API by default marks a turning point that modernizes JavaScript date and time handling after a 30-year delay. Options for eliminating at the design level such structural bugs as time zone shifts, leap seconds, and month-end discrepancies are finally available across standard runtimes.
Migrating to Temporal involves significant variations in effort based on domain count, database typing status, and regression testing scope. For consultations such as wanting to "sweep away Date and moment.js" or "structurally prevent timezone bugs from recurring," we provide individualized estimates starting from an inventory of your current systems. Feel free to contact us via our inquiry form.
