You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// 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 =newStringBuffer();
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.
The text was updated successfully, but these errors were encountered:
natebosch
added
the
area-test
Cross-cutting test issues (use area- labels for specific failures; not used for package:test).
label
Feb 9, 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.
We have at least one test that should be run in multiple timezones to get the full value:
sdk/tests/corelib/date_time11_test.dart
Lines 125 to 138 in d28828c
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.The text was updated successfully, but these errors were encountered: