Site timezone is no longer recognized by cache rebuild command
Describe the bug Since https://github.com/drush-ops/drush/commit/61eb7df2c1ebb99f75321056eefcf9207b751c02, the default timezone within the process changes from the timezone that is configured in the site configuration to the PHP configuration.
This can lead to downstream cache corruption like that seen in https://www.drupal.org/project/drupal/issues/3545132, and potentially other spots.
In our case, this manifests as the core Datelist element having incorrect dates saved to mysql causing everything to be off a day whenever the last cache clear was performed via Drush.
To Reproduce On a hosting environment whose server timezone is UTC and whose site timezone (system.date.yml) is set to America/New_York...
Flush the cache via the GUI - notice that datelist elements have a default timezone of America/New_York Flush the cache via Drush - notice that datelist elements have a default timezone of UTC
Expected behavior The configured site timezone should be set like it was in 12.x
Actual behavior The server timezone (as configured in php.ini) is set
Workaround
Changing CI/CD jobs to run php -d date.timezone="America/New_York" vendor/drush/drush/drush.php cr seems to be able to work around it.
System Configuration
| Q | A |
|---|---|
| Drush version? | 13.x latest |
| Drupal version? | 10.4.8 |
| PHP version | 8.3 |
| OS? | Linux |
Paging @Berdir, @alexpott, @DieterHolvoet, @greg-1-anderson since you were helpful at #1166. cache:rebuild doesn't bootstrap to full so we never get to the line we added in that PR.
Composer-y patch for anyone else needing a workaround:
diff --git a/src/Commands/core/CacheRebuildCommands.php b/src/Commands/core/CacheRebuildCommands.php
index 59cb63bc2..99c98ab5b 100644
--- a/src/Commands/core/CacheRebuildCommands.php
+++ b/src/Commands/core/CacheRebuildCommands.php
@@ -15,7 +15,8 @@ use Drush\Commands\DrushCommands;
use Drush\Drupal\DrushLoggerServiceProvider;
use Drush\Drupal\Migrate\MigrateRunnerServiceProvider;
-#[CLI\Bootstrap(DrupalBootLevels::NONE)]
+// @see https://github.com/drush-ops/drush/issues/6350
+// #[CLI\Bootstrap(DrupalBootLevels::NONE)]
final class CacheRebuildCommands extends DrushCommands
{
use AutowireTrait;
That patch could cause other problems like cache:rebuild being ineffective in fixing your site when your site cant bootstrap for whatever reason.
I'm not sure what Drush can do about this issue.
Agree about the patch, but for us, that's the lesser evil vs data corruption :laughing:.
Is Drush able to use .user.ini configurations? While I agree it's usually best to set the server timezone globally, some of the larger managed hosting providers don't allow end-user access to those configurations.
See https://github.com/drush-ops/drush/issues/3294#issuecomment-618962852