Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Since #3009377: Replace drupal_get_user_timezone with a date_default_timezone_get() and an event listener the datelist element uses the native date_default_timezone_get function to get the default timezone for elements. This can result in non-determinism if caches are flushed via the Admin UI versus CLI (drush).
Steps 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
This can lead to some hard to diagnose data quality problems for downstream users - where the persisted timezone is random.
See https://github.com/drush-ops/drush/issues/6350 for a possible fix in Drush -- but I think the potential for nondeterminism still exists even if the drush issue is resolved.
Proposed resolution
Do what was done in #3087606: Datetime::getInfo() caches user's timezone causing unpredictable timestamps. and don't set the default timezone in the element's getInfo() callback, since that's cached. The default timezone to use is dependent on the user and the site's configuration.
Remaining tasks
Review
User interface changes
NA
Introduced terminology
NA
API changes
NA
Data model changes
NA
Release notes snippet
NA
Issue fork drupal-3545132
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
luke.leberComment #5
bkosborneI think the default timezone should not be in the info data at all since it gets cached. A similar issue was found in the (much more widely used) Datetime element in [#13398554] and it was addressed there by pulling it out of the info data. Let's do the same here. I submitted a quick MR to see what fails, but I think we can add a test for it too.
Comment #6
bkosborneComment #7
bkosborneAdded a test (same one from Datetime's test). Ready for review.
Comment #8
smustgrave commentedRe-ran the failing tests and they were all random.
Ran the test-only feature and got https://git.drupalcode.org/issue/drupal-3545132/-/jobs/7875619 which properly shows the bug.
Reviewing #3087606: Datetime::getInfo() caches user's timezone causing unpredictable timestamps. and this does seem inline with that.
LGTM
Comment #9
luke.leber+1 RTBC
I ran a quick test after removing https://github.com/drush-ops/drush/issues/6350#issuecomment-3275964221 and the proper timezone seems to be used in all cases now.
Comment #11
alexpottCommitted and pushed 6e1cc4a09c1 to main and 7806a3ff92b to 11.x and 53bea0b5845 to 11.3.x. Thanks!
Nice find and fix. Backported to 11.3.x as a safe backport.