The title is only a placeholder until we discover more about the exact problem.

In #2490574: Validate that the publication date is in the future after adding the constraint to prevent past dates, I discovered a problem at comment 22 in helpTestScheduler where a date in the past was preventing a node being created, when the test code was intending to set a date in the future. However, when viewing the formatted date actually passed to the function it was in the future.

Looking at the generated page when attempting to save the new node, the example date beneath the input field was a time 11 hours in advance of my server time. I recall reading somewhere that drupal now uses a default timezone in Australia to make a big hourly difference with GMT. I think has got to be related to it.

I will get some screen grabs to more fully show this, and also search out where I read about the default timezone setting.

CommentFileSizeAuthor
#4 2630836-4-default_timezone_vs_users_timezone.patch856 bytesjonathan1055
#2 SchedulerTempWork.php_.txt3.89 KBjonathan1055

Comments

jonathan1055 created an issue. See original summary.

jonathan1055’s picture

jonathan1055 commented
StatusFileSize
new SchedulerTempWork.php_.txt3.89 KB

I've made some progress on this. I created a new working test file to try out all the combinations and to discover what was causing the problem. In summary I found that:

  1. There is no particular problem with the new date.formatter, it returns the same results as the old format_date
  2. There is no difference in results when using strToTime(-1 day) compared to time()-60*60*24
  3. If you avoid calling helpTestScheduler then the dates are all correct
  4. After calling helpTestScheduler the formatted date for -1 day is 13 hours back from current time instead of 24
  5. I think this is probably because we are in an Australia timezone which is GMT+11 hours, then -24 gives us the -13 hours we observe. I saw this mentioned somewhere as a specific edge-case for a default.
  6. After making a copy of helpTestScheduler and removing chunks of code, it is only when drupalLogin is called that the problem arises
  7. Adding a subsequent drupalLogout does not revert the date to the expect value. It seems we remain in the GMT+11 timezone

I have attached my working file, in case it helps anyone who wants to try this. Just save it to your /src/tests folder, i.e. the same location as the other test files, and remove the _.txt extension. Then it should be selectable from your /admin/config/development/testing page. Note that I am running in GMT, my local machine and webserver is set to GMT and my admin user is GMT. But running the interactive tests in other user timezones should still show the problem.

jonathan1055’s picture

jonathan1055 commented
Title: Default timezone problem » Default timezone vs User timezone in automated tests

After doing some more testing I can now see what is going on, and it's going to be a simple fix in the test code. The key to making the test scenarios match a real user is in ensuring that the adminUser is logged in when anything is done in the tests which mimic a real user. The problem we had was that the input date and time values were created before the adminUser was logged in, and thus they were formatted using the standard GMT/UTC timezone. But when the constraints were evaluated, as part of form submission, the user was logged in, so the formatted date and time was in the past according to if that value had been typed in by the user.

The simple fix is to put the drupalLogin() before creating the test date and time values. Then they will be consistent with the values being tested during evaluation of the constraints. Just like if a real user was doing it.

This sounds obvious now when explained like this, but I'm very happy to have solved it, as it was blocking progress on a couple of other constraint tests. I'll make a patch and add it here.

jonathan1055’s picture

jonathan1055 commented
Status: Active » Needs review
StatusFileSize
new 2630836-4-default_timezone_vs_users_timezone.patch856 bytes

Patch for /src/Tests/SchedulerFunctionalTest.php
This should run, but will produce the same number of passes and fails. I will then commit to the test branch and main branch, then re-queue the patch in #2490574: Validate that the publication date is in the future

Status: Needs review » Needs work

The last submitted patch, 4: 2630836-4-default_timezone_vs_users_timezone.patch, failed testing.

jonathan1055’s picture

jonathan1055 commented
Status: Needs work » Fixed

The commits for this patch are in #2594615: Automated testing in 8.x [meta] in comment #92.
The test results in #2490574: Validate that the publication date is in the future show that when the constraint is added we no longer get the failure 

✗	helpTestScheduler
fail: [Other] Line 60 of modules/scheduler/src/Tests/SchedulerTestBase.php:
Node with publish_on = 2015-12-11 17:28:01 was not created.

Hence marking this issue fixed!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.