Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[calendar] Wrong values on broadcasted fullday events with RRULE #3422

Open
eouia opened this issue Apr 9, 2024 · 4 comments
Open

[calendar] Wrong values on broadcasted fullday events with RRULE #3422

eouia opened this issue Apr 9, 2024 · 4 comments
Assignees

Comments

@eouia
Copy link
Contributor

eouia commented Apr 9, 2024

Platform: All

Node Version: v20.8.0

MagicMirror² Version: 2.27

Description: A repeated(BY RRULE) full-day event is shown as normal on screen, but it has the wrong value internally, so it delivers the wrong value on broadcasting as a notification.

Steps to Reproduce:

  1. Sample ics URL : https://calendar.google.com/calendar/ical/41bfece74ae469910f6414f6f0e6d7348bd1cd5eb442d3f415ade4388ea453f9%40group.calendar.google.com/public/basic.ics

  2. It has two events, one for single fullday event, and the other for repeated fullday event.
    image

  3. Those are displayed as a normal on the MM screen because Fullday event doesn't show the startTime.

image
  1. But inside of the logic, Repeated events have wrong parsed startTime.(Or at least it has wrong TZ information)
    To check this;
    image

modules/default/calendar/calendar.js line 417

This shows;
image
Repeated events don't start at 00:00. It starts at 02:00 I think it is due to Europe/Berlin Timezone (GMT+2)

Usually, it doesn't matter because full-day events do not show the exact time. But when the events are broadcasted, they deliver the wrong time value.

Copy link

github-actions bot commented Oct 5, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@sdetweil
Copy link
Collaborator

here is an updated test version of the fixes for all kinds of calendar date problems.

NOTE: the changed branch name
NOTE: this used the node-cal@0.19.0 library UNCHANGED

best to make a new folder and git clone there

git clone https://github.com/sdetweil/MagicMirror
cd MagicMirror
git checkout fixcaldates2 // <------ note this is a changed branch name
npm run install-mm
copy your config.js and custom.css from the prior folder
and the non-default modules you have installed…

this ONLY changes the default calendar
but DOES ship an updated node-ical library too

if you need to fall back, just rename the folders around again so that
your original is called MagicMirror

all the testcases for node-ical and MagicMirror execute successfully.

the ‘BIG’ change here is to get the local NON-TZ dates for the
rrule.between()

all the checking and conversion code is commented out or not used
the node-ical fixes are for excluded dates (exdate) values being adjusted for DST/STD time… waiting to submit that PR

one fix in calendar.js for checking if a past date was too far back,
but it never checked to see IF the event date was in the past… (before today) so it chopped off too many

and one change in calendarfetcher.js to put out a better diagnostic message of the parsed data… (exdate was excluded cause JSON stringify couldn’t convert the complex structure)

I added the tests you all have documented

please re-pull and checkout the new branch (I deleted the old branch)
and npm run install-mm again

@sdetweil sdetweil self-assigned this Oct 21, 2024
@sdetweil
Copy link
Collaborator

and you just have to examine the fulldayeevent:true flag and ignore the time.. ALL UTC dates have time (00:00:00)
and the time changes when viewing an event from a diff timezone.. as full date (date-type'date') is local time only

@sdetweil
Copy link
Collaborator

i updated the non-recurring content to match the recurring as well..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants