Selenium WebDriver date handling after Selenium 4 W3C compliance transition

Answer

Selenium 4 does not change how JavaScript Date objects are returned by executeScript or how date strings are interpreted by sendKeys for datetime‑local inputs. The browser supplies dates in its own local timezone, and the host OS locale determines the parsing of strings sent to the input. Consequently, Selenium cannot guarantee UTC‑normalized values across agents running in different time zones; any required conversion must be performed in the test code.

Confirmed facts

• Selenium WebDriver returns the exact Date object produced by the browser’s JavaScript engine via executeScript; no timezone conversion or normalization is applied.
• The W3C WebDriver standard (adopted in Selenium 4) only standardized timeout values in milliseconds; date handling remains outside the specification.
• Selenium 4 does not provide a timezone‑aware helper class (e.g., TimeZoneUtils) in any official language binding; such a utility is considered out of scope to keep clients lightweight.
• When a date string is sent to a datetime‑local input with sendKeys, the browser parses it using the host operating system’s locale, which can shift the stored UTC value if the locale offset differs from zero.

Likely explanation

Because the W3C specification deliberately left date handling to the browser, Selenium cannot enforce a universal timezone policy. Test authors must therefore normalize dates themselves—typically using java.time (Java), datetime (Python), or equivalent libraries in other bindings—or embed a small JavaScript snippet that converts to UTC before comparison.

Practical steps for reliable cross‑region testing

1. Retrieve dates: Use executeScript("return new Date();") and immediately convert the returned Date to UTC in your test language (e.g., Instant.ofEpochMilli(date.getTime()) in Java).
2. Assert on UTC: Compare the UTC‑converted value against an expected UTC instant, not against the raw browser‑local string.
3. Send to datetime‑local: Format the desired UTC instant as an ISO‑8601 string without timezone offset (e.g., yyyy-MM-dd'T'HH:mm) and adjust it for the host locale offset before calling sendKeys. A simple helper that adds the local offset to the UTC instant ensures the browser stores the intended UTC moment.
4. Verify stored value: After sendKeys, read back the element’s value attribute and convert it to UTC using the same locale‑aware logic to confirm correctness.

If you observe inconsistent results, confirm the host machine’s timezone offset (e.g., via TimeZone.getDefault().getOffset(System.currentTimeMillis()) in Java) as this is the only missing detail that would change the conversion strategy.