All 8.x daily tests were passing on d.o. up to Wed 28 March 00:16 GMT. The daily test for Thurs 29 March was not run until 13:45 GMT (late probably due to the security upgrade I am guessing) and failed the defautTime test. The message was
The node unpublish_on value is stored correctly.
Failed asserting that '1522528200' matches expected 1522524600.from the assertion on line 70. The actual time was 3600 seconds (1 hour) ahead of the expected time, so this looks like a daylight-saving time calculation problem. We've had this before and I thought that I had fixed the tests to avoid this. The test user has a timezone far away from GMT if I recall, something like Australia or New Zealand (where the clocks go back by one hour tommorrow 1st April).
This test failure was repeated in Friday 30th March test, which ran back at the usual time of around 00:15 GMT.
Then on Saturday 31st March 00:15 we get a different failure, still in DefaultTimeTest, but now the failed assertion is
The string "This post is unpublished and will be published Sunday, April 1, 2018 - 05:30." was not found anywhere in the HTML response of the current page.
This assertion is on line 64.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2957490-6.fix_test_for_daylight_saving_time_hardcode_rundate.patch | 6.28 KB | jonathan1055 |
| #5 | 2957490-5.fix_test_for_daylight_saving_time.patch | 6.25 KB | jonathan1055 |
Comments
Comment #2
jonathan1055 commentedThe differing assertions which failed led me to realise the reason for this test problem. When testing the default time, the publish-on date is +1 day and the unpublish-on date is +2 days. So on Thurs 29th March at 13:45 GMT (when the test was run) the time in Aus/NZ was already in the early hours of Friday 30th. Hence +2 days (for the unpublish-on time) was 1st April and into the new period after the clocks have changed. This caused the failure because the derived unpublish time was not the expected value. However +1 day (for the publsh-on time) was still before the clocks change, so these assertions were OK. The same behaviour happened on the Friday 30th test as this was run at 0:15 GMT so +1 day in Aus/NZ is around midday on Sat 31st, still before the clocks change.
However, when the tests ran on Sat 31st at 00:15 GMT the time in Aus/NZ is midday Sat 31st so +1 day is midday Sun 1st April, after the clocks change, hence the publish-on tests failed too.
The tests should run OK from tomorrow onwards. But they will fail again for 2 days on 5th and 6th October 2018, when the clocks go forward.
It would be nice to re-write the assertions so that the derived time takes care of daylight saving and we don't get these failures.
Comment #3
jonathan1055 commentedAs expected the tests pass again now
https://www.drupal.org/pift-ci-job/927751
Comment #4
jonathan1055 commentedHere is another exampe of the failure https://www.drupal.org/pift-ci-job/1251369
Unpublish_on found date 1554582600 = Sat 6 Apr 2019 - 21:30
Unpublish_on expected date 1554579000 = Sat 6 Apr 2019 - 20:30
Comment #5
jonathan1055 commentedThe source of the problem was that the scheduling dates were set using a simple addition of 23400 seconds to set the time to 6:30am. This gave the wrong time when the DST change happened between midnight and 6:30 on one of the scheduling days.
This change uses proper DateTime objects for the scheduling dates and that means the DST shift is correctly handled.
Comment #6
jonathan1055 commentedHere's the same patch with a faked rundate of 4 Oct 2019. In the test timzone this will put the unpublish date at Sun 6th Oct 6:30 which is after the next DST shift.
Comment #8
jonathan1055 commentedGood to get this solved. Although the final proof will be when the tests pass during the period 4th - 6th October 2019.