Read the statement by Michael Teeuw here.
calendar - wrong repeating count when using sliceMultiDayEvents
-
@sdetweil I know that parsing ics is a pita, but before I submit an issue at github, I wanted to have a quick discussion here in the forum.
When using the sliceMultiDayEvents config option the calendar shows an additional day. This is probably caused by the RRule parsing.
The code that causes this starts here
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:Dirk Test X-WR-TIMEZONE:Europe/Berlin BEGIN:VEVENT DTSTART;VALUE=DATE:20240918 DTEND;VALUE=DATE:20240919 DTSTAMP:20240916T084410Z UID:2crbv1ijljc2kt9jclkgu5hqa0@google.com CREATED:20240916T083831Z LAST-MODIFIED:20240916T083831Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:1 day single TRANSP:TRANSPARENT END:VEVENT BEGIN:VEVENT DTSTART;VALUE=DATE:20240919 DTEND;VALUE=DATE:20240920 RRULE:FREQ=YEARLY DTSTAMP:20240916T084410Z UID:6gb19havnq6vp2qput51e5rmml@google.com CREATED:20240916T083850Z LAST-MODIFIED:20240916T083850Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:1 day repeat TRANSP:TRANSPARENT END:VEVENT BEGIN:VEVENT DTSTART;VALUE=DATE:20240920 DTEND;VALUE=DATE:20240922 DTSTAMP:20240916T084410Z UID:06e9u1trbqi3jbvstvq4qqutau@google.com CREATED:20240916T083902Z LAST-MODIFIED:20240916T083902Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:2 day single TRANSP:TRANSPARENT END:VEVENT BEGIN:VEVENT DTSTART;VALUE=DATE:20240923 DTEND;VALUE=DATE:20240925 RRULE:FREQ=YEARLY DTSTAMP:20240916T084410Z UID:0ui78rk6hpcv8rmbb6nuonhmgg@google.com CREATED:20240916T083919Z LAST-MODIFIED:20240916T083919Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:2 day repeat TRANSP:TRANSPARENT END:VEVENT END:VCALENDAR
-
@MarcLandis said in calendar - wrong repeating count when using sliceMultiDayEvents:
sliceMultiDayEvents
thanks for the config
looking at the results without sliceMultiDayEvents
I see
so the parsing was correct, the visual, we only show the start date, even if multi-day
so both are ‘correct’ tho not informativewith split day
I don’t see any difference in the calendar parsing. (add “DEBUG” to the loglevel list in config.js)
and redirect the npm start output to a fileCalendar-Fetcher: Broadcasting 4 events from http://localhost:8090/modules/default/calendar/splitdays_test.ics.
only 4 events… so not calendar parsing,
the only place the split parm is used is in the front end… calendar.js
but my output is different than yours.I am using the develop branch, coming Oct 1. however I don’t see a documented change here
this split code was added in 2019…
also tested on master (2.28.0) with same 4 lines of resultsyou can get the develop branch and try it…
https://forum.magicmirror.builders/topic/14327/testing-new-fixes-or-solving-current-problems-with-next-release-codeI just copy/pasted your ics info in a file, unchanged
I tested with America/Chicago timezone.
-
@sdetweil I am pretty sure it has to do with timezone settings. I am going to test some things on my end.
btw: I have this problem for a long time and more or less always ignored it.
-
@MarcLandis so it doesn’t happen when setting the time zone to America/Chicago but it happens for Europe/Berlin.
-
@MarcLandis ok. system timezone.
-
@MarcLandis interesting…
change calendar.js 3 places
give it a trychange (line 633)
const maxCount = Math.ceil((event.endDate - 1 - moment(event.startDate, "x").endOf("day").format("x")) / ONE_DAY) + 1;
to
const maxCount = Math.round((event.endDate - 1 - moment(event.startDate, "x").endOf("day").format("x")) / ONE_DAY) + 1;
ceil takes 1.04 to 2, round to 1
let midnight = moment(event.startDate, "x") .clone() .startOf("day") .add(1, "day") .endOf('day') // add this (else its start of day, not end) line 641 .format("x");
and recalc of midmnight (line split like above for clarity) line 654
midnight = moment(midnight, "x") .add(1, "day") .endOf('day') // add this .format("x"); // next day works in Europe/Berlin and America/Chicago 2 bugs 1 count incorrect 2 loop control
-
@sdetweil this fixes it. The test calendar looks good and my real one with the birthdays (mostly affected one) is perfect. All other events are good too.
Thx for your help.
-
@MarcLandis i’ll submit an issue and a pr…
and a testcase
-
@MarcLandis
submitted PR https://github.com/MagicMirrorOrg/MagicMirror/pull/3543/
with new testcase to validatehopefully we will get it into next release Oct 1.
-
@sdetweil Thank you - even it doesn’t make it into the next release I have a way to manually fix it now.
-