Skip to content

Add support for running tests in multiple timezones #44928

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
natebosch opened this issue Feb 9, 2021 · 1 comment
Open

Add support for running tests in multiple timezones #44928

natebosch opened this issue Feb 9, 2021 · 1 comment
Labels
area-test Cross-cutting test issues (use area- labels for specific failures; not used for package:test).

Comments

@natebosch
Copy link
Member

We have at least one test that should be run in multiple timezones to get the full value:

void main() {
// The following code constructs a String with all timezones that are
// relevant for this test.
// This can be helpful for running tests in multiple timezones.
// Typically, one would write something like:
// for tz in <contents_of_string>; do TZ=$tz tools/test.py ...; done
var result = new StringBuffer();
for (int i = 0; i < daylightSavingChanges.length; i += 2) {
if (i != 0) result.write(" ");
result.write(daylightSavingChanges[i][0]);
}
runTests();
}

We are adding another test that needs to do extra work in order to determine interesting test cases for whatever timezone the test is running in. It would be better to have support for configuring the timezone in the test runner which would set the TZ environment variable for the subprocess. With that support we could hardcode the interesting test cases for one or more timezones.

@natebosch natebosch added the area-test Cross-cutting test issues (use area- labels for specific failures; not used for package:test). label Feb 9, 2021
@lrhn
Copy link
Member

lrhn commented Feb 10, 2021

Testing time zone logic is fairly hard. I can do spot testing by setting the time zone locally (or use the debug tool in a browser for web code), but there are lots of weird special cases that we'll never have regression testing for without a way to control the time zone in our automatic testing.

Something like // Requirements=TZ:Europe/Copenhagen or // SharedOptions=--tz=Europe/Copehagen would be sufficient (the former is more proper, it's not a compiler flag, but a "how to run the test" option). It should preferably work for both native and web tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-test Cross-cutting test issues (use area- labels for specific failures; not used for package:test).
Projects
None yet
Development

No branches or pull requests

2 participants