Timezone issue with community events

Status of related issues:

Looks like the 1st related issue #2898235: Date's Time Zone Handling doesn't keep time/zone static → was fixed.

Does drupal.org use the patch at the 2nd related issue 🐛 Problem with timezone handling (caused by date_get_timezone_db returning only UTC) Needs work which is still marked as 'Needs work' at the time of this comment? If it doesn't could we try it? If it is already applied and the issue is unrelated to that, its been a while since I did D7 but I'd be happy to spin it up and see if I can reproduce and raise a new issue with the D7 Date module.

Confirmation the issue still exists:

We are still seeing the same issue for https://www.drupal.org/community/events/drupal-ai-meetup-2024-10-17 → for example.

Here is the edit screen, configured to be 7pm CEST

When viewing the event in CEST, 7pm is correctly shown:

When viewing the event in non-CEST (in this case BST), it says 8pm CEST which is incorrect (its also not 8pm BST, it'd be 6pm BST). This is causing lots of people to be very confused about when the event date actually starts. Thankfully the ones that ask we can reply to, but the ones that don't ask we are concerned they will miss the event sadly:

🐛 Problem with timezone handling (caused by date_get_timezone_db returning only UTC) Needs work has a database update, so is not a good idea to deploy. It would leave us in a unique migration path, no migration of data as stored with that patch at that point in time would be reasonable to expect. And the maintainers might go a different route in resolving the issue, also leaving the data in an uncharted place.

This issue is still creating confusion for members of our local communities. I've even seen media partners do posts about events on social promoting the wrong times because of it. Would love to see it fixed or some kind of simple workaround, like hiding the wrong time field and displaying another.

Has this been fixed? I am getting the correct times now for Stanford WebCamp and others look correct as well.

No changes here, I think the behavior is likely different if you are logged in, which could help get it right in some cases.

I fully expect we’ll fix this as a side effect of upgrading to modern Drupal. Effort would be better spent in getting the community events themed with the new brand and landing page refreshed.

Interesting. I did test it logged in and logged out. Although other tests I was in PST and not EST. Not sure that would correct the time. Before it was showing May 7th - 8th. Now it is showing the correct May 8th - 9th.

Changing the status here to postponed. After talking with @drumm at DrupalCon Atlanta, we determined that the best way to achieve this is to expedite the migration to the new site/brand. That should resolve this complicated date issue as well as unblock other issues we want to work on.

Given that at this point makes little sense to fix this in Drupal 7 date, could we at least have an alert notifying anonymous users that the time is not to be trusted, pointing to this known issue?

The above suggestion is easy to do and at least would inform users creating/editing the events. Here is a quick MR that would show a warning: https://git.drupalcode.org/project/drupalorg/-/merge_requests/363/diffs

It'd show like this:

It doesn't fix the underlying issue, but at least it informs event creators about it. We've had 3 slack messages about this in the past month where we always inform users about this issue and the workaround which we suggest in the warning.

If this solution is not wanted, we can put the issue back into "Postponed".

The warning on edit is now deployed.

It didn’t cross my mind before that we could theoretically fix the display somewhere in custom field formatting, without the underlying date module bug being fixed. Assuming enough time zone information is stored consistently.