Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There must have a been a recent core commit to D8.2 which has affected date processing. Our DefaultTime tests now fail on my localhost, running D8.2.0-rc2, which I upgraded from rc1 recently. I have also just checked on D.O. and the same tests also now fail https://www.drupal.org/pift-ci-job/485019
Comment | File | Size | Author |
---|---|---|---|
#4 | 2809627-4.default_time_and_daulight_saving.patch | 3.21 KB | jonathan1055 |
|
Comments
Comment #2
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedOK, it's nothing to do with D8.2.0-rc. The tests fail on D.O at D8.3 and also locally on 8.1. All versions of Drupal have the same failure and there have been no changes or commits to the tests since yesterday (when they were all running OK).
It must be something common which affects all versions - maybe something to do with the actual date and time of running the tests? The default time of 6:30 is set for the next day, and this worked fine. But the simpletest user is running in timezone AEST which is GMT+10 and not in daylight saving at the moment. The tests fail because the anticipated time to check for is being shown as 7:30
$publish_time => 2016-10-02 07:30:00
but the nodes are actually scheduled for 6:30 because the message saysThis post is unpublished and will be published 2016-10-02 06:30:00.
I don't know why this has suddenly decided to fail, though.
Comment #3
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedI can see what is going wrong - AEST are not currently in daylight saving time, but if we calculate
+1 day
for the scheduled date then that will be in daylight saving.taken from https://greenwichmeantime.com/time-zone/australia/
If tests are run now [Fri 30th Sept 21:00 GMT] then the AEST time is Sat 1st Oct 07:00, and '+1 day' is Sun 2nd Oct, which is in Daylight saving. Hence the default time and derived time are one hour out and the tests fail.
I predict that the tests will all run correctly tomorrow. But it would be nice to fix the tests, so that we do not waste time on it on every approch to a DST boundary. #2203485: Convert default time to users timezone during node edit is probably related to this issue.
Comment #4
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedThe code that derives the default time, in
TimestampDatetimeNoDefaultWidget
is working fine. In the test code, we do not need to use format_date to derive the text we are looking for in messages and date fields - we know the value so can use a simple fixed string.Here's a patch attached to fix the failing test.
Comment #5
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedGood. That has fixed the test. However I am not going to commit this right now, because I want to see exactly when the existing test will start passing again.
It was important to get the fix written and tested quickly because at 14:00 GMT today (1st Oct) the AEST time will be 00:00 on Sun 2nd Oct (GMT+10). Although according to https://www.timeanddate.com/time/change/australia the daylight-saving period does not start until 02:00 AEST, which is 16:00 GMT.
So up to 16:00 GMT the existing test will probably still fail. However, after 16:00 GMT, which is 02:00 AEST the Australia daylight-saving period starts and their clocks move forward to 03:00. At this point the simpletest user will be DST mode and this will match with the scheduled publish time which is also in DST mode.
Comment #6
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedThe tests are now all passing without the patch. https://www.drupal.org/pift-ci-job/485667
It must have been 14:00 GMT that they started working, which was 00:00 on 2nd Oct in AEST. I thought it would not be until 16:00 because before then the tests 'local time' is still not in daylight-saving mode, as explained above. However, that is not really important. The main thing is that with this patch we should not get a repeat of the failures during the 24 hours approaching the next daylight-saving change.
Comment #8
jonathan1055 CreditAttribution: jonathan1055 as a volunteer commentedCommitted.