All-day dates start early

Created on 3 December 2023, 7 months ago
Updated 11 June 2024, 14 days ago

Problem/Motivation

Testing out the module with Smart Date 4.0.3 (with Recurring sub-module). I had one problem, and now after updating Calendar View from 2.1.6 to 2.1.7 tonight, I have two problems.

I have a live example on a demo/test site: https://d10.developond.xyz/calendar

(Sorting issue now moved to its own post: https://www.drupal.org/project/calendar_view/issues/3411991 πŸ› All-day Events don't sort properly with recurring Smart Date events Active )

The new problem as of 2.1.7 is that now All-day events show that they begin the day before they're supposed to and then span the proper day.

On my demo site, you can see this with 3 all-day events - one that's supposed to span Dec. 11-15 but is spanning Dec. 10-15, and then Christmas Eve which is only supposed to show on the 24th and Christmas Day which is only supposed to show on Dec. 25.

On the demo site, each date field has a hidden Start Date field (Content: Date), using the Smart Date Formatter, Start only, default display, unchecked "show all values in the same row". This serves as the Calendar View date field reference in the Month format settings. The time is then displayed as a separate views field so that the user visually only sees the time in the calendar page.

Steps to reproduce

  1. Build a monthly calendar view.
  2. Add an all-day event in a timezone other than UTC.

Proposed resolution

I can't suggest anything specific in the coding.

Re: all-day events starting "early", something changed from 2.1.6 to 2.1.7.

Remaining tasks

πŸ› Bug report
Status

Active

Version

2.1

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada michaelschutz

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

Merge Requests

Comments & Activities

  • Issue created by @michaelschutz
  • πŸ‡¨πŸ‡¦Canada michaelschutz

    edited for clarity

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

    For what it's worth, the calendar view module was working perfectly for me on Drupal core 10.1.6. Then when I installed Drupal core 10.1.7, it started displaying an all-day date (12/25/2023) on two days, 12/24 and 12/25. Just makes me wonder if some date issues are being caused by core 10.1.7 and not by this calendar_view module. Both 2.1.6 and 2.1.7 versions worked for me with core 10.1.6.

  • πŸ‡¨πŸ‡¦Canada michaelschutz

    Thanks for the additional insight, @msac. My demo site is still on Drupal 10.1.6, so there might be a combination of things? I wish I could help narrow this down.

  • πŸ‡¨πŸ‡¦Canada michaelschutz

    So I just updated another sandbox site to D10.2 and it's still exhibiting the same behaviour (with calendar_view 2.1.7). I just now realized that there's a hover/tooltip behaviour on the event shown on the calendar events, and it gives the details of the event - date, time, timezone.

    So there's something going on with the timezone conversion. I have my site set to Pacific Time (right now that's UTC -8), and the event on the calendar is subtracting 8 hours, not from GMT, but from midnight. (Screenshot is attached showing that calendar_view thinks the Christmas Day event starts at 16:00 PST on the 24th instead of 0:00 on the 25th.

    I tried it out with another random timezone, (Amsterdam, UTC +1) and the same calculation was made for that time zone, pushing the date displayed onto the 26th as well as the 25th. So that seems to confirm what I'm thinking.

    That will allow me to peek into the code to look for a bug, but as I'm not at all skilled with code I don't know if I can find anything. But maybe this gives @matthieucarset or someone else the road map to find what's happening?

  • πŸ‡¨πŸ‡¦Canada michaelschutz

    OK just one more quick note until I have more time. On this sandbox site, with D10.2.0 and CalView 2.1.7, all-day events are not being displayed properly, as above. This only applies to all-day events and not events with start/end times within the one date; those are displayed properly.

    I downgraded to CalView 2.1.6 without changing anything else on the site, and all dates display properly. Re-upgrading to 2.1.7 causes the shift to all-day events having their start times be displayed wrongly (on my site, with timezone set to UTC -8, as if it started at 16:00 the day before).

    The all-day dates display properly on just a basic unformatted list of events, so I can confirm it is related to CalView calendars.

    So it seems that something has changed between 2.1.6 and 2.1.7 that causes this. Once I have more time I can try to dig into the changes, but maybe Mattieu or someone else can pinpoint that much more quickly than me.

  • πŸ‡ΊπŸ‡ΈUnited States camhoward New Hampshire, USA

    I'm having the same issue with all-day events starting early with Calendar View 2.1.7 on a Drupal 9.5.11 site, so it's not limited to Drupal 10+.

    When the timezone is set to America/New York, all day events display as starting at 7 p.m. the day before (UTC -5). Even if I set specific times for an event, such as as starting at 12:01 a.m. and ending at 11:59 p.m. on the day of the event, instead of using the "All Day" option in Smart Date, the calendar displays the date as starting at 7 p.m. the day before and ending at 6:59 p.m. the day of the event.

    The time shift also happens when using the Drupal core Date field instead of a Smart Date field.

    And, as @michaelschutz found, if I change the "Time zone override" for the date field in the View to UTC, all-day events display correctly on the calendar.

  • πŸ‡ΊπŸ‡ΈUnited States kenrbnsn New Jersey

    This is occurring on events that aren't all-day events. Changing the "Time zone override" for the date field in the View to UTC fixes the problem.

    D10.2
    Calendar View: 2.1.7
    php 8.1.26

  • πŸ‡¨πŸ‡¦Canada michaelschutz

    removing content re: sorting

  • lucas.vidaguren β†’ made their first commit to this issue’s fork.

  • I think this patch should fixit

  • 3405794-1 patch replaces mistaken 3405794-0 one

  • The 3405794-2.patch replaces 3405794-1.patch

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

    I had the same issue and the #15 patch fixed it for me. Thanks!

  • πŸ‡ΊπŸ‡ΈUnited States hbrokmeier Wisconsin

    Patch #15 fixed this issue for me as well.

Production build 0.69.0 2024