Direct Answer
No. Selenium does not provide a flag, capability, or binding option that forces executeScript to return a JavaScript Date as an ISO-8601 UTC string. The reliable fix is to avoid returning the Date object itself and instead return a primitive from the injected script.
Why the Returned String Varies
When executeScript completes, the driver serializes the script's return value. For a Date object, this commonly produces a string via Date.toString() or a JSON conversion step. That string reflects the browser's locale, the operating system's time zone, and driver-specific serialization behavior. The WebDriver specification does not mandate a canonical representation for Date returns, so cross-browser and cross-locale differences are expected rather than bugs.
Confirmed: Selenium bindings expose the raw serialized value without an option to request UTC or ISO-8601 formatting. Likely explanation: the mismatch originates in the browser/driver serialization layer, not in a Selenium configuration setting.
Implications of Standardizing the Format
Changing executeScript to always return ISO-8601 UTC would require coordinated changes across the WebDriver specification, browser drivers, and Selenium bindings. It is not a Selenium-only flag. While standardization would improve determinism, it could break existing tests and tools that parse the current locale-dependent strings. Because the behavior is version-sensitive across browsers, drivers, protocol versions (W3C vs. legacy), and OS locale settings, you should not assume a specific format holds across your entire CI matrix without verification.
Recommended Workaround
Return a primitive from the injected script so the binding receives a stable value regardless of locale:
// Selenium injected script
const d = new Date(); // or your existing Date object
return {
iso: d.toISOString(),
millis: d.getTime(),
asString: String(d)
};
- Use
d.getTime() when your test needs ordering or equality; epoch milliseconds are locale-independent.
- Use
d.toISOString() when a UTC ISO-8601 string is required. Slice the first 10 characters only if you intend a UTC calendar date.
- If you need a local calendar date, do not use
toISOString(). Define the target time zone explicitly in the script and format the parts you need, because UTC conversion can shift the date across midnight boundaries.
Verification Steps
- Execute a script that reads the browser clock at execution time, returning
{ iso: new Date().toISOString(), millis: new Date().getTime(), asString: String(new Date()) }, and inspect the binding result on each browser/driver.
- Repeat with different OS/browser locales and time zones;
iso and millis should remain consistent, while asString may change.
- For an existing page Date variable
d, return d.getTime() and d.toISOString(), then assert against expected values converted to UTC in the test language.
Do not parse Date.toString() with a fixed pattern. Month and day names, ordering, and GMT offset formatting vary by locale and platform. Prefer formatting inside the injected script over changing the browser's time zone or locale, which can affect unrelated application behavior. Read the browser clock at execution time rather than hard-coding a timestamp from the test runner.
selenium