Timezone issue with community events

Created on 12 August 2020, over 4 years ago
Updated 16 October 2024, 6 months ago

There seems to be an issue with Community Events on d.o with timezones.

I attempted to create an event to start at 6:30 p.m. in Chicago / Central Time Zone, which would be 18:30 on July 21st.

Drupal Event Link: https://www.drupal.org/community/events/struggles-with-drupal-for-site-b... β†’

Attaching screenshots with the following scenarios:

Anonymous (not logged in to Drupal)
Expected: 18:30 CDT
Actual: 13:30 CDT

Logged in to Drupal in Eastern Time Zone
Expected: 17:30 EDT
Actual: 17:30 CDT

Logged in to Drupal in Chicago / Central Time Zone
Expected: 18:30 CDT
Actual: 18:30 CDT

Admin settings as I set up the event in Chicago / Central Time Zone:

πŸ› Bug report
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

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.

  • πŸ‡¬πŸ‡§United Kingdom scott_euser

    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:

  • πŸ‡ΊπŸ‡ΈUnited States drumm NY, US

    πŸ› 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.

  • πŸ‡ΊπŸ‡ΈUnited States heatherwoz Seattle

    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.

  • πŸ‡ΊπŸ‡ΈUnited States sikofitt

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

  • πŸ‡ΊπŸ‡ΈUnited States drumm NY, US

    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.

  • πŸ‡ΊπŸ‡ΈUnited States sikofitt

    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.

  • πŸ‡ΊπŸ‡ΈUnited States heatherwoz Seattle

    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.

Production build 0.71.5 2024