w3c
Add ability to set timezone
ECMA402 has the concept of "Default Timezone" in sec 6.4.3 and there is a new HTML "timezonechange event" proposal (whatwg/html PR 3047). It will be nice if webdriver could support the setting of the timezone so web tests could easily test these
I put together a "Set Timezone WebDriver Extension" proposed API . It will be nice if that could be folded into w3c/webdriver
Notice Chromium already implement #3047 behind a flag (see https://chromium-review.googlesource.com/c/chromium/src/+/1994529/ ) and I am trying to implement the above proposal into chromedriver in https://chromium-review.googlesource.com/c/chromium/src/+/2512788
The usage of this new command will not only help to test the newly added timezonechange event but also help developers to write tests for under different host timezone much easier. Please let me know how could I contribute to this specification. I am a regular TC39 and ECMA402 subcommittee members.
Also ref: https://docs.google.com/document/d/1QAMHl7qIfGyFmWxta8OpR2YwivwaVgX_ixG17QWAgd0/edit#
@anba @sffc @littledan @gibson042 @zbraniecki @rwaldron @spectranaut @rkirsling @mathiasbynens - For the impact to testing about ECMA402 features
@mathiasbynens drafted up this text for HTML to specify the Web Driver command for timezone change in https://github.com/littledan/html/pull/1 . I don't really understand the rationale for putting the command in the HTML spec rather than the WebDriver spec. Do the WebDriver editors have any opinion here?
Reposting @stephenmcgruer's comment here:
Thanks for the fixes, @mathiasbynens . I don't understand where it's appropriate to land the WebDriver specification and asked the editors at w3c/webdriver#1559 (comment) , but I don't think this should block the patch from landing; we can refactor it later if needed.
I am not a WebDriver editor, but can give thoughts from the perspective of someone who has helped a few teams add WebDriver extensions for browser-testing purposes. We have historically encouraged spec authors to add the 'automation/testing support' section to the same specification as the feature that the automation is for. This helps keep the automation APIs 'in sync' with the feature APIs, and also keeps the main WebDriver spec leaner and clearer (rather than be a laundry list of extensions).
There is significant prior art here; permissions, reporting, sensors, webauthn, and background fetch all have webdriver extensions in their spec.