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

Reoccuring monthly event on the xth day of the week fails to show first entry if UTC time is next day #3351

Open
twsouthwick opened this issue Jan 14, 2024 · 7 comments
Assignees

Comments

@twsouthwick
Copy link

Platform: Docker image

Node Version: 20

MagicMirror² Version: v2.26.0

Description: I live in Pacific Time Zone and set up a reoccurring event that is in the evening that goes every 3rd thursday of the month. The entry doesn't show up on my magic mirror. It appears that if the start time of the event is the next day UTC the calculation of what "3rd Thursday" means ends up skipping the first time it is on the calendar.

Steps to Reproduce: Have an entry similar to the following in the ics file:

BEGIN:VEVENT
DESCRIPTION:\n
RRULE:FREQ=MONTHLY;UNTIL=20240620T130000Z;INTERVAL=1;BYDAY=3TH
UID:040000008200E00074C5B7101A82E00800000000610FD5404047DA01000000000000000
 010000000A076DC7A6C28004EBB22B7894AA3102E
SUMMARY:Test1
DTSTART;TZID=Pacific Standard Time:20240118T060000
DTEND;TZID=Pacific Standard Time:20240118T063000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20240114T232211Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-REQUESTEDATTENDANCEMODE:DEFAULT
X-MICROSOFT-ISRESPONSEREQUESTED:FALSE
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:\n
RRULE:FREQ=MONTHLY;UNTIL=20240621T040000Z;INTERVAL=1;BYDAY=3TH
UID:040000008200E00074C5B7101A82E0080000000066CDDB594047DA01000000000000000
 01000000094CA99E776C1594E9DC563B709F12D39
SUMMARY:Test2
DTSTART;TZID=Pacific Standard Time:20240118T210000
DTEND;TZID=Pacific Standard Time:20240118T213000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20240114T232211Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-REQUESTEDATTENDANCEMODE:DEFAULT
X-MICROSOFT-ISRESPONSEREQUESTED:FALSE
END:VEVENT

NOTE: This repro is dependent on the date 1/18/2024 visible on the calendar

Expected Results:

Both events should show up on 1/18/2024 for their first time in the reoccurrence

Actual Results:

Only the 6am entry is shown

image

Configuration:

		{
			module: "calendar",
			config: {
				calendars: [
					{
						broadcastPastEvents: true,
						maximumNumberOfDays: 20,
						name: "family",
						url: '...'
					},
				],
			}
		},
@sdetweil
Copy link
Collaborator

in the container,

cd to the

MagicMirror folder (opt?).. (where node_modules is located)   I don't use the docker container, so don't know 
##  get back to the prior calendar parser
npm install node-ical@0.16.1

@tetron
Copy link

tetron commented Jan 15, 2024

npm install node-ical@0.17.0 should also work (node-ical@0.17.1 is the version that depends on the problematic version 2.7.1 of the rrule library).

@twsouthwick
Copy link
Author

Thanks - I ended up canceling that entry in the reoccurring event so it didn't really matter. Hopefully ical/rrule get fixed to handle it correctly - for me it was an inconvenience, but an odd one to track down what was happening.

@mholzma
Copy link

mholzma commented Jun 3, 2024

I believe I am still having a similar issue but I don't want to open up a new issue. I have a repeating event that continuously shows up on the following day. My assumption is that it is the RRULE problem although I have tried using the node-ical@0.17.0 or 0.16.1 versions. I also wondered if it was confusing my locale even though I have it set to en-US and am located in Chicago / central time zone.

The only thing I am seeing different in the ICAL feed for an event that is working and one that is not is:
Works: RRULE:FREQ=WEEKLY (although this one is from 6-8pm)
Doesn't: RRULE:FREQ=WEEKLY;WKST=SU (this is just 7-8pm)

@sdetweil
Copy link
Collaborator

sdetweil commented Jun 3, 2024

@mholzma yes the wkst seems to be the cause

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

see new branch
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

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

5 participants