All-day dates start early

edited for clarity

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.

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.

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?

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.

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.

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

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

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

Patch #15 fixed this issue for me as well.

Just saw a new release for D11 - any chance we can get the MR with this patch from #15 approved and committed into a 2.1.9 release?

Is anyone able to supply a patch that works with the latest dev branch? I need an unreleased fix and this fix as well.

Hi, adamcadot
I've rebased the !26 branch so it doesn't conflicts with 2.1.x.

It seems to be workinkg! It would be great if it could be approved to be in 2.1.9

It is working well! Thanks!

Thank you for your help and please forgive the delay in merging this change.

Trusting the RTBC status, it's merged on 2.1.x and will have a new release soon.

Automatically closed - issue fixed for 2 weeks with no activity.