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 · 3 comments

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.

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

4 participants