DEV Community: Vishal Singh

JavaScript Temporal Reached Stage 4: A Practical Migration Guide Beyond Date

Vishal Singh — Mon, 10 Aug 2026 06:45:55 +0000

JavaScript's Date object has carried the web for decades, but almost every experienced developer has a story about it: an off-by-one-day bug, a daylight-saving surprise, a month numbered from zero, or a date-only value that silently became a timestamp.

In July 2026, the TC39 Temporal proposal reached a Stage 4 draft. That is a major standardisation milestone: the API has completed the proposal process and is ready to become part of the ECMAScript standard.

But Stage 4 does not mean you can assume every current browser already has Temporal. MDN still marks the API as limited availability. The practical approach is to learn the model now, use feature detection, and add the official polyfill when your support policy requires it.

This guide explains the mental model, the most useful types, and a safe migration path from Date.

What you will learn

how Temporal models dates, times, instants, zones, and durations
which Temporal type fits each common use case
how to migrate from Date without a risky rewrite
how to handle current browser support safely

Why Date causes so many bugs

Date tries to represent several different concepts with one mutable object:

an exact instant on the global timeline
a calendar date such as a birthday
a local wall-clock time
a date and time in a named time zone
a duration between two values

Those concepts are not interchangeable.

Consider the string 2026-08-10. It might mean a birthday, a billing date, or midnight in some time zone. Turning it into a Date can introduce a time zone that the original value never had.

Date also has historical API traps. Months are zero-indexed in the numeric constructor, parsing behaviour has edge cases, and methods can mutate an existing value.

Temporal solves the modelling problem by using separate immutable types.

The Temporal types you should know

You do not need to memorise the whole API. Start by choosing the type that matches the data.

Temporal.PlainDate

Use PlainDate for a calendar date with no time and no time zone.

Good examples include:

birthdays
public holidays
invoice due dates
check-in dates

const launchDate = Temporal.PlainDate.from("2026-08-10");
const reviewDate = launchDate.add({ months: 1 });

console.log(launchDate.toString()); // 2026-08-10
console.log(reviewDate.toString()); // 2026-09-10

Temporal values are immutable. add() returns a new value; it does not change launchDate.

Temporal.PlainTime

Use PlainTime for a wall-clock time without a date or time zone.

const openingTime = Temporal.PlainTime.from("09:30");
console.log(openingTime.hour); // 9

This works for a recurring local concept such as "the store opens at 09:30." It does not identify one exact moment globally.

Temporal.Instant

Use Instant for an exact point on the timeline.

This is the closest Temporal equivalent to a Unix timestamp or a Date used as an event timestamp.

const deployedAt = Temporal.Instant.from("2026-08-10T06:30:00Z");
console.log(deployedAt.epochMilliseconds);

Instants are useful for logs, database timestamps, audit events, and API data that ends in Z or includes an offset.

Temporal.ZonedDateTime

Use ZonedDateTime when the named time zone matters.

const meeting = Temporal.ZonedDateTime.from(
  "2026-08-10T10:00:00+05:30[Asia/Kolkata]"
);

console.log(meeting.timeZoneId); // Asia/Kolkata
console.log(meeting.toString());

The named zone is important because an offset such as +05:30 and a time zone such as Asia/Kolkata are different kinds of information. Time-zone rules can change, and many regions use daylight saving time.

Temporal.Duration

Use Duration for an amount of time.

const sprint = Temporal.Duration.from({ weeks: 2 });
console.log(sprint.toString()); // P2W

Be careful when converting calendar units into clock units. A day is not always exactly 24 hours in a zone with daylight-saving changes. Temporal makes you provide the context when that context is required.

A DST-safe example

Imagine a recurring meeting at 10:00 in New York. Adding one calendar day should keep the meeting at 10:00 local time, even if the UTC offset changes.

const beforeChange = Temporal.ZonedDateTime.from(
  "2026-03-07T10:00:00-05:00[America/New_York]"
);

const nextDay = beforeChange.add({ days: 1 });

console.log(nextDay.hour); // 10
console.log(nextDay.offset); // may change with DST rules

This is exactly why a named time zone is more useful than manually adding 86,400,000 milliseconds.

A practical migration map

Do not replace every Date in one giant refactor. First classify what each value means.

Date-only form values

Old approach:

const selected = new Date(input.value);

Safer Temporal model:

const selected = Temporal.PlainDate.from(input.value);

An HTML date input returns a date-only string. PlainDate preserves that meaning without introducing midnight or a time zone.

API timestamps

If an API returns an exact timestamp:

const createdAt = Temporal.Instant.from(apiResponse.createdAt);

If your UI needs a local representation, convert it with an explicit zone:

const local = createdAt.toZonedDateTimeISO("Asia/Kolkata");
console.log(local.toLocaleString());

Current time

For a timestamp:

const now = Temporal.Now.instant();

For the current calendar date in a chosen zone:

const todayInIndia = Temporal.Now.plainDateISO("Asia/Kolkata");

These two calls answer different questions, which is the point.

Calendar arithmetic

Old code often adds milliseconds:

const tomorrow = new Date(Date.now() + 24 * 60 * 60 * 1000);

For a calendar date, write the intent directly:

const tomorrow = Temporal.Now.plainDateISO().add({ days: 1 });

Interoperating with existing Date code

Most projects will use Date and Temporal together during migration.

Convert a Date to an Instant:

const legacyDate = new Date();
const instant = Temporal.Instant.from(legacyDate.toISOString());

Convert an Instant back to Date:

const legacyAgain = new Date(instant.epochMilliseconds);

This boundary is useful when an existing library still expects Date.

Do not convert a PlainDate to Date unless you decide what time and time zone that calendar date should represent. That decision cannot be inferred safely.

Browser support and the polyfill

Before using the global Temporal object, check your runtime support.

if ("Temporal" in globalThis) {
  // Native Temporal is available.
}

For production code that must work in browsers without native support, use the @js-temporal/polyfill package and follow its current installation documentation.

import { Temporal } from "@js-temporal/polyfill";

A polyfill has bundle-size and compatibility implications, so apply it deliberately. For a small isolated date task, an existing well-tested library may still be the right short-term choice. For new domain modelling, Temporal gives the platform a consistent long-term direction.

Common mistakes to avoid

Using PlainDateTime for a real event

PlainDateTime has a date and clock time but no time zone. "10 August at 10:00" is not one exact global moment until a zone is supplied.

Use ZonedDateTime or Instant for events that must be coordinated across locations.

Storing only a formatted string

A string such as "10 Aug, 11:30 AM" is presentation, not durable data. Store a machine-readable Temporal string or the underlying structured value, then format it for the user.

Assuming an offset is a time zone

An offset tells you the relationship to UTC at one moment. A named time zone carries rules for future and historical changes.

Comparing objects with normal operators

Temporal objects intentionally avoid ambiguous coercion. Use methods such as Temporal.PlainDate.compare(), equals(), since(), or until().

Ignoring availability

Stage 4 is a standards milestone, not proof that all users have upgraded browsers. Test the environments in your support matrix and provide a polyfill or fallback when needed.

A simple decision checklist

Before creating a Temporal value, ask:

Is this only a calendar date? Use PlainDate.
Is this only a clock time? Use PlainTime.
Is this one exact timestamp? Use Instant.
Does a named time zone affect the meaning? Use ZonedDateTime.
Is this an amount of time? Use Duration.

That small modelling decision prevents many bugs before arithmetic or formatting begins.

Conclusion: clearer intent is the real upgrade

Temporal is valuable not because it has more methods than Date, but because the type tells another developer what the value means.

A birthday is not a timestamp. A meeting in New York is not just an offset. One calendar day is not always 24 hours.

Temporal puts those distinctions into the API.

The safest adoption plan in 2026 is straightforward: classify existing date values, migrate one boundary at a time, use native support when available, and include the polyfill where your browser matrix needs it.

Sources

Tags: javascript, webdev, temporal, tutorial

Stop Guessing Browser Support: A Practical Guide to Web Platform Baseline in 2026

Vishal Singh — Mon, 10 Aug 2026 06:09:49 +0000

Liquid syntax error: 'raw' tag was never closed

Why Lighthouse and Real-User Core Web Vitals Show Different Results

Vishal Singh — Wed, 22 Jul 2026 08:34:57 +0000

You run Lighthouse and get a green performance score. Then you open PageSpeed Insights and the Core Web Vitals assessment says your page needs improvement.

Or the opposite happens: Lighthouse reports a slow page, while real-user data looks healthy.

Nothing is necessarily broken. The two results answer different questions.

Lighthouse gives you lab data from one controlled test. Chrome UX Report, usually called CrUX, gives you field data collected from real Chrome users. Understanding that difference can save hours of debugging the wrong problem.

Lab data: a controlled experiment

Lighthouse loads a page using predefined device and network conditions. A typical mobile run applies CPU and network throttling and usually behaves like a new visitor with a cold cache.

This makes Lighthouse useful because the test can be repeated. You can change your code, run it again, and compare the results under similar conditions.

Lighthouse is particularly useful for:

finding render-blocking resources
identifying large images or JavaScript bundles
diagnosing main-thread work
detecting layout shifts during the initial load
catching performance regressions before deployment

But a Lighthouse result is still one test from one environment. It is not a survey of every person visiting your website.

Field data: what real users experienced

CrUX collects performance measurements from eligible real Chrome users. PageSpeed Insights uses this dataset in its field-data section.

Instead of testing one simulated device, field data includes a distribution of real visits across different:

phones and computers
network speeds
locations
cache states
browsing sessions
user behaviours

CrUX generally reports a rolling 28-day view and evaluates Core Web Vitals at the 75th percentile. In simple terms, the reported value is intended to represent an experience that at least 75% of visits met or beat.

This makes field data the better answer to: “What experience are our users actually getting?”

Why the numbers disagree

1. The tested device is not your users' devices

A Lighthouse mobile test simulates a particular level of CPU and network performance. Your visitors may use faster devices, slower devices, or a completely different mix.

One lab run cannot reproduce that entire distribution.

2. Lighthouse often tests a cold load

A lab test commonly loads the page without the benefit of previously cached assets. Returning users may already have fonts, scripts and images cached.

This can make Lighthouse look worse than field data. The reverse can happen when real users face slow networks, overloaded devices or third-party content that did not appear in the lab run.

3. Real users interact with the page

A default Lighthouse audit focuses heavily on the initial page load. Real visitors scroll, open menus, accept cookie banners, load more content and use interactive components.

This difference is especially important for CLS and INP.

A page may have no obvious layout shift during loading but shift later when a lazy-loaded component, advertisement or embedded widget appears. CrUX can capture that real experience even when a basic Lighthouse run does not.

Similarly, Interaction to Next Paint depends on actual interactions. A load-only test cannot reproduce every slow click, tap or keyboard action your users encounter.

4. You may be comparing a URL with an entire origin

PageSpeed Insights shows URL-level field data when enough data is available. When it is not, it may fall back to origin-level data.

That means you could accidentally compare:

Lighthouse data for one specific page
CrUX data representing many pages across the domain

Always check whether the field section says “This URL” or “Origin” before investigating a mismatch.

5. Field data is historical; Lighthouse is happening now

Lighthouse tests the current version of the page. CrUX uses a rolling window of recent user experiences.

After deploying a performance improvement, your Lighthouse result can improve immediately while CrUX changes gradually as new visits replace older data.

6. The page is not identical for every visitor

A/B tests, ads, consent banners, personalisation, authentication state and third-party scripts can change what gets loaded.

Lighthouse may see one version while different groups of users see something else. Even repeated Lighthouse runs can fluctuate when the page or underlying conditions change.

Which result should you trust?

Trust field data when judging the experience your real users receive and whether your site meets Core Web Vitals in practice.

Use Lighthouse to diagnose problems, reproduce controlled scenarios and prevent new regressions.

It is not field data versus Lighthouse. A useful workflow needs both:

Field data tells you that a real problem exists and how widespread it may be.
Lab data helps you understand, reproduce and fix specific causes.

The overall Lighthouse performance score is also not the same thing as the Core Web Vitals assessment. Compare the individual metrics—LCP, INP and CLS—rather than expecting the two headline results to match.

A practical debugging workflow

Step 1: Read the field-data label

In PageSpeed Insights, confirm whether the CrUX result represents the exact URL or the whole origin.

Step 2: Compare individual metrics

Identify whether the disagreement is mainly in LCP, INP or CLS. Each metric points toward different causes.

Step 3: Re-run Lighthouse consistently

Use the same test mode, device category and environment. Run it more than once and look for a pattern instead of treating one score as absolute truth.

Step 4: Investigate what the lab test misses

If field data is worse, examine real user journeys:

scroll through the full page
interact with menus and forms
test consent banners and embedded widgets
check slower devices and networks
investigate post-load layout shifts
collect your own Real User Monitoring data when possible

The web-vitals JavaScript library can help collect field measurements and attribution information from your own users.

Step 5: Use Lighthouse diagnostics to fix reproducible causes

If the lab and field metrics point in the same direction, Lighthouse audits can help locate heavy resources, long tasks, delayed content and layout-shift culprits.

Step 6: Monitor after deployment

Confirm the immediate improvement in a controlled test, then watch field data over time. CrUX will not fully reflect a deployment immediately because its reporting window includes earlier visits.

A simple way to remember it

Lighthouse is a crash test performed under controlled conditions.

CrUX is information collected from cars being driven by real people on real roads.

The crash test helps engineers find weaknesses. The road data shows what drivers actually experience. You need both to build something reliable.

The next time Lighthouse and Core Web Vitals disagree, do not ask which tool is wrong. Ask what population, time window, device conditions and user journey each result represents.

Sources:

Grok Build Is Now Open Source: What Developers Can Learn from Its Coding-Agent Architecture

Vishal Singh — Mon, 20 Jul 2026 10:15:56 +0000

AI coding tools are often discussed as black boxes: you give them a task, they inspect a repository, run commands, edit files, and return a result. Grok Build is now a useful exception.

SpaceXAI has open-sourced Grok Build, its terminal-based coding agent and full-screen TUI. The public repository exposes the harness behind the product, so developers can inspect how context is assembled, model responses are parsed, tools are dispatched, and long-running work is managed.

What has been open-sourced?

The published Rust code includes:

the agent loop that connects model responses to tool calls
tools for reading, editing, searching, and running commands
the terminal UI, including plan review and inline diffs
the extension system for skills, plugins, hooks, MCP servers, and subagents

This matters because an AI coding agent is more than a model. The surrounding harness decides what context the model sees, which actions it can take, how failures are handled, and how a developer stays in control.

Three useful takeaways for developers

1. Context assembly is a product feature

A coding agent must decide which files, instructions, tool results, and previous decisions belong in the next model request. Better context is not simply more context; it is the right information at the right time.

2. Tool execution needs a feedback loop

The model can propose an edit or command, but the harness must execute it, capture the result, surface errors, and feed useful evidence back into the next step. Reliability comes from this loop, not from one perfect prompt.

3. Extensibility should have clear boundaries

Grok Build supports skills, plugins, hooks, MCP servers, subagents, AGENTS.md instructions, and configuration. The architecture is a good reference for anyone building an internal developer agent that must adapt to different repositories and workflows.

Can you run it yourself?

The repository contains the Rust source for the Grok CLI/TUI and its agent runtime. You can compile it locally, and the official announcement says it can be pointed at local inference through config.toml. Prebuilt installers are also available for macOS, Linux, and Windows.

One important distinction: an open-source agent harness does not automatically make every hosted model or service free. The code, model access, authentication, and usage costs are separate layers, so check the current terms before choosing a setup.

Why this release is worth studying

Even if you do not plan to switch coding assistants, the repository is valuable as a real-world reference for agent loops, terminal UX, tool dispatch, sandboxing, memory, and extensibility.

Open-source coding agents make an important question easier to answer: not only "What can the model do?" but also "How does the system decide, act, verify, and recover?"

Would you explore the Grok Build source to learn from the architecture, contribute your own extension, or run it with local inference?