Postman Sandbox and System Time Zone Interoperability
0 reputation · 27 Mar 2023, 12:34 UTC
0 reputation · 27 Mar 2023, 12:34 UTC
Postman utilizes a Node.js-based Sandbox for Pre-request Scripts and Tests, allowing the use of JavaScript Date objects and the bundled moment.js library to handle ISO 8601 conversions and regional offsets.
When executing scripts that rely on the local system time for API assertions, there is a potential discrepancy in how the runtime environment resolves the system time zone. Specifically, the execution context may differ when running the same collection via the Postman Desktop agent compared to the Postman Web agent.
This variance introduces uncertainty when validating time-sensitive responses in distributed environments or CI/CD pipelines where the agent's host time zone may not align with the API server's UTC expectations.
32775 reputation · 27 Mar 2023, 19:11 UTC
Postman’s pre‑request and test scripts run in a Node.js‑based sandbox. The JavaScript Date object reflects the time zone of the host process:
new Date(), toString(), and toLocaleString() return values in the local zone.toISOString() and all UTC‑specific methods (getUTC*) always return UTC, independent of the host zone.When the Desktop agent launches, it inherits the operating system’s time zone unless the TZ environment variable is overridden.
The Postman Web agent executes the sandbox inside the browser’s JavaScript context. Consequently, Date objects there use the browser’s local time zone (the same zone shown in the browser’s date/time settings). Postman does not force a fixed UTC clock for the Web sandbox; UI timestamps may be displayed in UTC, but script‑generated dates follow the browser zone.
date.toISOString() or date.getTime() for epoch milliseconds.moment.utc(date).format() or date.toLocaleString(undefined, {timeZone: 'UTC'}).new Date().toString() or toLocaleString() for assertions; those will differ between Desktop (OS zone) and Web (browser zone).TZ variable (e.g., TZ=UTC Postman) and ensure the browser’s timezone is set to the same zone (or adjust scripts to convert to that zone).In a test script, log:
console.log('Local:', new Date());
console.log('ISO :', new Date().toISOString());
console.log('Locale:', new Date().toLocaleString());
Compare the output with your system’s time zone (Desktop) and the browser’s time zone (Web). The ISO string will always match UTC, confirming that UTC‑based methods are safe for cross‑agent consistency.Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 27 Mar 2023, 20:52 UTC
In both Desktop and Web agents, the sandbox’s moment() constructor defaults to the local time zone of the host process (OS zone for Desktop, browser zone for Web). If you need a zone‑aware moment without loading the full moment‑timezone data, you can create a UTC moment and then offset it using the zone offset retrieved from new Date().getTimezoneOffset() (which returns minutes difference from UTC). For example:
const offsetMinutes = -new Date().getTimezoneOffset(); // positive if west of UTC
const localMoment = moment.utc().add(offsetMinutes, 'minutes');This yields a moment that reflects the same local zone as moment() but works even when the sandbox’s bundled moment.js lacks timezone data. Remember that getTimezoneOffset() changes with DST, so recalculate it per request if your script runs across a DST transition.