Simpletest should set a system timezone in setUp

Lets see what breaks.

We run TestBot outside of the root directory to make sure we don't have any code that accidentally relies on or only works when the base URL is /. Choosing a TZ at the far edge is similar. Dates in are stored as UTC in the database. By choosing something close to the extreme, you will expose bugs that assume UTC b/c you often have day rollover when the TZ is applied to the value pulled from the database. Thought would need to go into whether a large positive value or a large negative value make more sense for finding potential bugs.

I think the proper solution is to pick a non-UTC zone, and then fix the tests (or code) that relies on UTC.

+++ b/core/modules/config_translation/src/Tests/ConfigTranslationUiTest.php
@@ -465,8 +465,10 @@ public function testDateFormatTranslation() {
-      $formatted_date = format_date(494015820, $id, NULL, NULL, 'fr');
+      $formatted_date = format_date(494015820, $id, NULL, 'Europe/Berlin', 'fr');
       $this->assertEqual($formatted_date, 'Tue', 'Got the right formatted date using the date format translation pattern.');

Not sure if this is correct? How did you arrive at the TZ for Berlin? Did you pick it or is that what happened to be in the dated b/c is is the default in MAMP? I think that TZ in particular should be avoided b/c it is the MAMP default.

Based off of the comments in ConfigTranslationUiTest and LocaleConfigTranslationTest, I think this is the correct fix. However, I am not really sure what the intent of those tests are because Tuesday in French is mardi (or at least that is what the Google machine tells me), so I don't know why the French langcode is passed in but the English text is the expectation.

Haven't looked at the other fails yet.

I'm also expecting this to fail periodically in the Datetime tests, depending on when the test actually runs. Later today, I am also going to post two testonly patches: one with a TZ with a large positive offset and one with a large negative one to see what happens. But, I am hoping to find a table that matches up the PHP zone names with their UTC offsets instead of trying to guess which will be closest to the international date line.

Ok, did some poking around. It looks like the dates in the RDF tests are being created in the host system's time zone (for me, UTC-4). The expectation in the test is using the zone we set in WebTestBase::setUp (UTC+9). Didn't figure out if it is an Easy_RDF problem bypassing the zone that WebTestBase creates, or if some comment code is actually executing in the host system's container and not the test system's container.

Also note that #15 had a fail in the datetime tests that wasn't present in others. My work in #2399211: Support all options from views fields in DateTime formatters has a fix for this.

#19-2: just made #2498619: Unit tests should use a default timezone other that UTC

#19-3: I agree. In the tests I fixed, I have no idea what that test is trying to achieve, though, other than it expecting what is stated in the comment above the lines that changed.

This needed a reroll. Also changed the TZ to Australia/Sydney, to mirror #2498619: Unit tests should use a default timezone other that UTC. This is an extreme, but not too extreme, TZ that participates in DST.

This should come up green.

The problem had to do with calling PHP's date() directly. In some of the fails, it was grabbing the simpletest time zone, in others it was grabbing the system time zone.

I updated the tests to use format_date, and Drupal\rdf\CommonDataConverter() to use \Drupal::service('date.formatter'), and both to force the timestamp to UTC (which shouldn't matter for this purpose, since the TZ offset it part of the output and will be interpreted by anything using it). Not sure if the CommonDataConverter() part would really be considered in scope, but we have a service for formatting timestamps, so we should use it instead of the low level function.