Contrib.social

Datelist::getInfo() caches user's timezone causing unpredictable timestamps.

Open on Drupal.org →
Created on 17 February 2022, over 2 years ago
Updated 17 June 2024, 2 days ago

Problem/Motivation

The same problem as we had with the Datetime element:
https://www.drupal.org/project/drupal/issues/3087606 →

As getInfo() is only called on cache clear, in some cases we have wrong timezone in $element['#date_timezone'].

Steps to reproduce

In our use case, we have Datelist element as a Webform field. Interesting, when editing Webform Submission from Admin UI, everything works fine, the correct timezone (default one: Europe/Vienna) is in use. But we also have the same Webform exposed on a page, so logged-in users can create/edit submissions. Even with the same user as above (admin), we have the wrong timezone (UTC) in Datelist element, so it makes a big confusion when editing dates in the submission.

Proposed resolution

the same as is already done with the Datetime element

🐛 Bug report
Status

Closed: cannot reproduce

Version

11.0 🔥

Component
Datetime  →

Last updated 1 day ago

Created by

dejan0

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇺🇸United States smustgrave

    Still applies to D10

  • Status changed to Postponed: needs info about 1 year ago
  • Comment about 1 year ago →
    🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
    +++ b/core/lib/Drupal/Core/Datetime/Element/Datelist.php
@@ -39,7 +39,6 @@ public function getInfo() {
-      '#date_timezone' => date_default_timezone_get(),

    the only place in core that sets the default timezone based on a user-provided value is the TimeZoneResolver

    But that only happens during a config import if the system date config object is being changed.

    So I'm wondering what in your project is calling date_default_timezone_set with a user-provided value

  • Status changed to Closed: cannot reproduce 2 days ago
  • Comment 2 days ago →
    🇦🇺Australia acbramley

    Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

    As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" 1 year ago.

    Since further information has not been provided, I'm marking the issue "Closed (cannot reproduce)". If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active".

    Thanks!

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024