Calendar shows late day events on next day but at correct time

[natmash]

@sdetweil

timedatectl returns America/Chicago. On my pi I run via a docker container, but I have also tested locally with just npm start and the same thing happens.

[sdetweil]

@natmash the docker container is another system, it needs a timezone property, defaults to utc

like this

[natmash]

Just coming back to this after a few weeks unable to get to it.

No luck. In addition, it still is only related to recurring events, whereas single events are set correctly. Even in a series of events the first event is fine but events after are wrong.

[sdetweil]

@natmash can you turn on debug

add

 ,"DEBUG"

to the logLevel list in config.js

redirect the output of npm start to a file

npm start >somefile.txt

[sdetweil]

@natmash

and maybe post one event from your cal ics file which demonstrates the issue

[MMRIZE]

@natmash @sdetweil
It seems a bug on the default calendar module. One of my CX3 user also reported it so I looked inside.
https://github.com/MMRIZE/MMM-CalendarExt3/discussions/146#discussioncomment-9380307

[sdetweil]

@MMRIZE i expect so, I’d like to see the event from the ics to see what we can do

[natmash]

BEGIN:VEVENT
CREATED:20240904T053053Z
DTEND;TZID=America/Chicago:20240910T211500
DTSTAMP:20240925T005517Z
DTSTART;TZID=America/Chicago:20240910T201500
LAST-MODIFIED:20240925T005515Z
LOCATION:Dance Class
RELATED-TO;RELTYPE=X-CALENDARSERVER-RECURRENCE-SET:2D48CA37-FCE5-4E16-871
9-1F47160BDBA3
RRULE:FREQ=WEEKLY;UNTIL=20250601T011500Z
SEQUENCE:3
SUMMARY:Wife Barre Class
UID:39669340-7AFD-4685-9BD6-6CE4B715486E
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
END:VEVENT

[sdetweil]

@natmash thanks

[natmash]

Barre Class, with dates: ["2024-09-11T01:15:00.000Z","2024-09-18T01:15:00.000Z","2024-09-25T01:15:00.000Z","2024-10-02T01:15:00.000Z","2024-10-09T01:15:00.000Z","2024-10-16T01:15:00.000Z","2024-10-23T01:15:00.000Z","2024-10-30T01:15:00.000Z","2024-11-06T01:15:00.000Z","2024-11-13T01:15:00.000Z","2024-11-20T01:15:00.000Z","2024-11-27T01:15:00.000Z","2024-12-04T01:15:00.000Z","2024-12-11T01:15:00.000Z","2024-12-18T01:15:00.000Z","2024-12-25T01:15:00.000Z","2025-01-01T01:15:00.000Z","2025-01-08T01:15:00.000Z","2025-01-15T01:15:00.000Z","2025-01-22T01:15:00.000Z","2025-01-29T01:15:00.000Z","2025-02-05T01:15:00.000Z","2025-02-12T01:15:00.000Z","2025-02-19T01:15:00.000Z","2025-02-26T01:15:00.000Z","2025-03-05T01:15:00.000Z","2025-03-12T01:15:00.000Z","2025-03-19T01:15:00.000Z","2025-03-26T01:15:00.000Z","2025-04-02T01:15:00.000Z","2025-04-09T01:15:00.000Z","2025-04-16T01:15:00.000Z","2025-04-23T01:15:00.000Z","2025-04-30T01:15:00.000Z","2025-05-07T01:15:00.000Z","2025-05-14T01:15:00.000Z","2025-05-21T01:15:00.000Z","2025-05-28T01:15:00.000Z"]
[2024-09-28 11:26:06.920] [DEBUG] Rule has byweekday, checking for correction
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Sep 10 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Sep 17 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Sep 24 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Oct 01 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Oct 08 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Oct 15 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Oct 22 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 5) and hour=20 >= 24-5, Adding 1 day to Tue Oct 29 2024 20:15:00 GMT-0500 (Central Daylight Time)
[2024-09-28 11:26:06.920] [DEBUG] West of GMT (tzOffset: 6) and hour=19 >= 24-6, Adding 1 day to Tue Nov 05 2024 19:15:00 GMT-0600 (Central Standard Time)

[sdetweil]

@natmash yes… code I put in to fix another bug, in the repeating rule parser… it used to return the day prior UTC date and right time… so I adjusted it.
now in this one case it returns the correct UTC date…

if I fix this it breaks other testcases…

looking for another option

[sdetweil]

@natmash so, I think I finally have a fix for this.
Would you like to try it?

Which MagicMirror version are you using?

[MarcLandis]

@sdetweil I am going to test your fix with my calendar too, as it was the cause for the initial fix.

[sdetweil]

@MarcLandis you want it on 2.28 or 2.29?

[MarcLandis]

@sdetweil 2.29 please

(2.28 is too old :) )

[sdetweil]

@MarcLandis understood, but I don’t want to force upgrade to test

[sdetweil]

@MarcLandis @natmash

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

best to make a new folder and git clone there

git  clone https://github.com/sdetweil/MagicMirror
cd MagicMirror 
git checkout fixcaldates
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)

[MarcLandis]

@sdetweil I testet your branch and so far it looks good with my test calendar and also with my real ones.

[sdetweil]

@MarcLandis thanks. i still have some reported issues. so use it and let me know. will advise when i make nect updates

we wouldn’t release til jan anyhow, so we have time

[sdetweil]

@natmash please see my latest test update this entry is now added to the testcases run

(I had NOT fixed it before today)