Should StackBlitz unify timestamps to browser local time or keep UTC for Node preview?

Question

When a StackBlitz project runs, client‑side Date objects reflect the browser’s local time zone, while the same code in the Node.js backend (WebContainers) logs dates in UTC because the container’s system clock is fixed to UTC. The file explorer shows modification timestamps converted to the browser’s local time, so the same moment appears three different ways: in the preview console, in backend logs, and in the UI.
This split creates uncertainty for date‑sensitive logic when collaborators are in different regions and leaves no clear source of truth for timestamps stored or displayed by the application. StackBlitz does not expose a setting to force a single zone (e.g., UTC) across client and server contexts, nor does it let users change the WebContainer’s timezone to match their locale.
Teams must therefore decide whether to adopt a universal UTC convention, rely on the browser’s local time, or add custom conversion logic on both sides.

Should StackBlitz introduce a project‑level option to lock all timestamps to UTC for both client and server previews?
Would aligning the WebContainer’s system timezone to the browser’s locale eliminate the mismatch without breaking existing code?
Is it practical to provide a utility that automatically normalizes Date values between the preview console and the file explorer timestamps?

Wasi · Answer

The Recommendation: Maintain UTC for Node Previews
StackBlitz should maintain UTC for Node.js (WebContainer) previews and avoid unifying timestamps to the browser's local time. The most stable architectural path is to provide a project-level option to lock the client-side environment to UTC, ensuring a single source of truth across the entire stack.

Why Local Time Alignment is Risky
Aligning the WebContainer's system timezone to the browser's locale would introduce non-deterministic behavior. Because WebContainers are designed to mimic production server environments—which almost universally use UTC—forcing a local offset would create a "works on my machine" discrepancy. Code that passes tests in a local-aligned preview might fail in a real production deployment where the system clock is UTC.

Proposed Implementation Strategy
Rather than attempting to sync the backend to the frontend, the following approach resolves the mismatch without breaking existing code:

Project-Level UTC Lock: Introduce a setting that forces the client-side JavaScript environment to treat dates as UTC. This prevents the "split-brain" effect where the browser and server report different times for the same event.
  Explicit TZ Environment Variable: Allow users to manually set the TZ environment variable within the WebContainer configuration. This gives power users control without imposing a risky global default.
  Avoid Automatic Normalization: A utility that intercepts all Date values is impractical and likely to introduce performance overhead or bugs in third-party libraries that expect standard JS Date behavior.

Verification Steps
To confirm the current discrepancy in your environment, run the following commands:
// Run in both Browser Console and Node Preview
console.log(new Date().toString());

// Run in WebContainer Terminal
printenv TZ
If the browser returns a local offset (e.g., GMT-0500) while the Node preview returns UTC, the environment is operating in the default split-state.

Missing Diagnostic Detail
Are you utilizing any specific third-party date libraries (e.g., Day.js, Luxon) that currently handle the conversion, or are you relying solely on the native Date object?

Should StackBlitz unify timestamps to browser local time or keep UTC for Node preview?

1 answer

The Recommendation: Maintain UTC for Node Previews

Why Local Time Alignment is Risky

Proposed Implementation Strategy

Verification Steps

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments