Timestamp mismatch between Pre-request Script output and {{$isoTimestamp}} resolution

Short answer

Generate the regional timestamp once inside the Pre-request Script, store it with pm.environment.set() or pm.collectionVariables.set(), and reference that stored variable in the request body. Do not use {{$isoTimestamp}} in the same request when the value has to match your script's logic. It is a separate clock read that always produces UTC, so it will not agree with a regional value even when the timing gap between the two reads is zero.

Confirmed behaviour versus the likely explanation

Confirmed: pre-request scripts run before the request is built and sent, and dynamic variables such as {{$isoTimestamp}} are resolved later, during request preparation. Confirmed: {{$isoTimestamp}} is UTC in ISO 8601 form. Confirmed: the sandbox exposes the standard JavaScript Date object, so new Date() reads the system clock of whichever process executes the script.

The likely explanation for the mismatch you are seeing is two separate reads of the clock, one in the script and one at resolution time, combined with a formatting difference. The timing gap is usually milliseconds to a second. The timezone difference is systematic: a regional value differs from UTC by the offset, not by a few milliseconds.

One clarification worth keeping: new Date().toISOString() is not local time. It converts the current instant to UTC. If your script output looks local, the formatting call is doing that, not toISOString().

Steps for this case

1. Choose an IANA zone identifier such as America/New_York, never a numeric offset.
2. Format the timestamp once in the Pre-request Script and store it.
3. Reference the stored variable in the body.

const zone = 'America/New_York';

// 'sv-SE' yields YYYY-MM-DD HH:mm:ss, easy to normalise
const parts = new Date().toLocaleString('sv-SE', {
  timeZone: zone,
  hour12: false
});

const regionalTimestamp = parts.replace(' ', 'T');

pm.collectionVariables.set('regionalTimestamp', regionalTimestamp);
console.log('regionalTimestamp =', regionalTimestamp);

Then in the body:

{
  "timestamp": "{{regionalTimestamp}}"
}

Daylight Saving Time

Passing a timeZone option to toLocaleString delegates the offset to the runtime's IANA timezone database, which applies the correct offset for that specific date, including DST transitions. A hard-coded +05:00 or -04:00 cannot do this. Note that the resulting string carries no offset suffix, so a consumer cannot tell which zone it represents. If the API requires an explicit offset or a trailing Z, either send UTC plus a separate zone field, or compute the offset for that instant and append it.

Verification

1. Open the Postman Console.
2. Send the request.
3. Compare the logged value with the value in the sent request body; they should be byte-identical.
4. To observe the resolution-timing gap separately, put {{$isoTimestamp}} and a script-set new Date().toISOString() in a scratch request and compare. Expect a small delta and a UTC value.

The one detail that changes the recommendation

Where does the request actually execute: the desktop client on your machine, or a cloud or agent runner? If it is an agent, the clock read by new Date() belongs to that host, not to you, and the stored value will reflect it. Confirm this before treating the stored timestamp as your regional time. The exact ordering of dynamic variable resolution should also be verified against your installed Postman release, since it is not a documented contract and may change between versions.