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.

fjgarlin → changed the visibility of the branch 7.x-3.x to hidden.

I created https://git.drupalcode.org/project/drupalorg/-/merge_requests/385/diffs

I think that this code will solve the inconsistencies.

It recalculates the timestamps with the database timezone (which is the one used to store the original timestamps) and then renders them with the timezone set in the date field.

In order to test, check both logged in vs logged out at: https://fjgarlin-drupal.dev.devdrupal.org/community/events/drupalcamp-sp...

@fjgarlin I can´t login on you link.
Nevertheless, these are the results of my tests:
- Not logged on https://fjgarlin-drupal.dev.devdrupal.org/community/events/drupalcamp-sp...

18 Sep 2025 at 16:00 CEST
to 21 Sep 2025 at 00:00 CEST

- Not logged on https://www.drupal.org/community/events/drupalcamp-spain-2025-2025-09-18 →

18 Sep 2025 at 12:00 CEST
to 20 Sep 2025 at 20:00 CEST

- Logged on https://www.drupal.org/community/events/drupalcamp-spain-2025-2025-09-18 →

18 Sep 2025 at 10:00 CEST
to 20 Sep 2025 at 20:00 CEST

None of the starting times equals, end time are also different. I don´t think it works :(

Thanks for the review.

The link above has this in the backend:

So it is correct.

From the backend screenshoot, it looks good for anonymous users. I can´t test logged users.

I took a different approach that avoids regex. I also noticed that if I edit an event that was created with a different time zone, it is not loaded correctly for the edit form, so that could be another source of times being made incorrect.

Yeah, the dates shown in the edit form are not correct. Probably due to the same issue. The previous suggestion would only affect the viewing of the node, as the edit page was/is ok. I'll try to find a cleaner way.

Small changes from your approach. Everything seems consistent on https://fjgarlin-drupal.dev.devdrupal.org/community/events/drupalcamp-sp... logged in vs logged out and in the edit page.

Backend setup for the above:

I was seeing some inconsistencies when viewing events which I have not edited on dev. Saving them did update the time shown to match what I saved. I suspect people have entered times that got the display to somewhat work, but were stored technically incorrectly. So I think this should be an improvement, but will change the appearance of what people have managed to save.

It think it will be best to email the 30 people with upcoming events and ask them to double check their events as this is deployed. In case there’s a camp or other event this weekend, we can plan to do this Monday.

I also considered activating this logic only for events saved after when this is deployed. So the old behavior would be retained until the event is updated. I decided against that, since it would be more complex, and we want to keep the future migration as straightforward as we practically can.

Query to get people with upcoming events:
SELECT DISTINCT n.uid FROM field_data_field_date_of_event fdf_doe INNER JOIN node n ON n.nid = fdf_doe.entity_id WHERE fdf_doe.field_date_of_event_value > now();