Hoppscotch ↔ Browser Local Time Zone: How to Convert Request‑History Timestamps?

Direct answer

Yes — a time-zone selector is the right feature, but the conversion should happen only at display time. Keep the stored and exported timestamps as ISO 8601 UTC strings exactly as they are today, and render them through Intl.DateTimeFormat with a chosen timeZone. This gives users local or selectable zones without touching existing history exports or mock-server payloads.

Why UTC strings make this easy

An ISO 8601 string ending in Z is unambiguous, so new Date('2026-10-13T11:28:50.664Z') parses reliably in every modern browser. The browser already ships an IANA time-zone database, so daylight-saving transitions are handled for you — no offset math of your own, no bundled tz library required for basic needs.

Implementation sketch

Three pieces cover the whole feature:

• Detect the browser zone as the default: Intl.DateTimeFormat().resolvedOptions().timeZone.
• Offer a selector of IANA names (e.g. Asia/Kolkata, America/New_York), persisted in user settings alongside an "UTC" option for users who prefer raw values.
• Format at render time only:

const fmt = new Intl.DateTimeFormat('en-GB', {
  timeZone: userZone,            // e.g. 'Asia/Kolkata' or 'UTC'
  dateStyle: 'medium',
  timeStyle: 'medium'
});
fmt.format(new Date(entry.timestamp)); // entry.timestamp stays the raw UTC string

Protecting export compatibility

The confirmed-safe rule: exports and storage stay UTC ISO 8601, always. If you want local time in exports, add it as a separate, opt-in column (e.g. timestamp_local) rather than rewriting the existing field — changing the primary field would break diffing and reproducibility of history files. Also avoid toLocaleString() output in any machine-readable artifact; its format varies by browser and locale.

Mock server

The same principle applies: mock responses that embed timestamps should emit UTC ISO strings and let the client render locally. A zone setting there is optional presentation sugar, not a correctness feature, so it can wait.

What you can do today, without any feature

For one-off conversion, paste the string into the browser console:

new Date('2026-10-13T11:28:50.664Z')
  .toLocaleString('en-US', { timeZone: 'Asia/Kolkata' });

Verify the result shows the expected +5:30 shift, and confirm new Date(...).toLocaleString() with no options matches your OS local offset.

Caveats

This guidance assumes a current Hoppscotch version without a native zone setting — check the settings UI and recent release notes first, since the feature set may have changed. Very old browsers or embedded runtimes can have incomplete IANA zone support, so test your target environment. One open question worth deciding before building: should the selector live per-user in settings, or per-workspace for shared/team history views? That choice affects where the preference is stored, not the conversion approach itself.