[Bug] Calendar Hour not showing correct when converting from lower timezone to higher one (UTC+2 -> UTC+3)

[Raducu-Alexandru]

Environment

MagicMirror² version: 2.31.0
Node version: 22.15.0
npm version: 10.9.2
Platform: Raspberry pi

Which start option are you using?

npm run start

Are you using PM2?

No

Module

calendar

Have you tried disabling other modules?

• Yes
• No

Have you searched if someone else has already reported the issue on the forum or in the issues?

• Yes

What did you do?

Description:

When trying to convert the hour received from the .ics file, which is in the UTC format, the module converts it to one hour later (at least for my example)

Steps to reproduce the issue:

Load an .ics file with an event where the time is set in UTC and the timezone is UTC+2, and try to view it in a timezone with UTC+3

What did you expect to happen?

To show the hour correctly in UTC+3

What actually happened?

The hour was 1 hour in the future in UTC+3

Additional comments

Solution:

The file modules/default/calendar/calendarfetcherutils.js on line 687 has a line that is commented out for calculating the eventDiff in the case described above. Furthermore, the commented line is incomplete

Line:

//eventDiff = eventDiff; //- nowDiff

Correct line:

eventDiff = nowDiff - eventDiff;

Explanation for the solution:

When calculating the diff between a timezone of smaller and greater (UTC+2 to UTC+3) we need to only get the diff from the bigger - smaller (3 - 2 = 1), before resolving this line the startMoment on line 691 was calculated using the eventDiff from line 640, which was 2, so it added 2 hours instead of 1, to a time already in UTC+2, and by doing so it converted it to an UTC+4 instead of an UTC+3.

Participation

• I am willing to submit a pull request for this change.

[sdetweil]

can you post an ics with the event which fails
and the timezone of the MagicMirror system

[Raducu-Alexandru]

I can try and give you the event not the ics as it is from work, and I can t really simulate creating en event from a timezone UTC+2. I will look and give you what I can. The timezone of the magic mirror is the on efor Bucharest (UTC+3) and the incomming on is Brussels (UTC+2)

[sdetweil]

all I need is the

BEGIN:VEVENT
...
END:VEVENT

you can change the text, uuid, just don't leave out any fields.

from a terminal window if you do

curl -sL the_ical_url >somefile.txt
somefile.txt will contain the text form of the calendar, its what we process.

just need that one event

[Raducu-Alexandru]

Perfect. I will try and get this for you today

[Raducu-Alexandru]

Hi,
I managed to get the event from the ics file and removed all sensitive data from it.

BEGIN:VEVENT
DTSTART:20250506T071000Z
DTEND:20250506T072500Z
DTSTAMP:20250510T230333Z
ORGANIZER;CN=email_removed:mailto:email_removed
UID:UID removed
CREATED:20250505T061601Z
DESCRIPTION:Description removed
LAST-MODIFIED:20250505T150700Z
LOCATION:Microsoft Teams Meeting
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:title removed
TRANSP:OPAQUE
END:VEVENT

Let me know if you need anything more. Thank you!

[sdetweil]

thanks

[sdetweil]

this event, (I edited the actual ics to change date to 0520 so it is in the future, vs past)

DTSTART:20250506T071000Z

is NOT on the UTC+2 TZ.. it is on UTC, and we correctly adjust it +3 for Bucharest.. shows at 10am.(utc+3)

if it was a Bucharest TZ event, it would look like this

DTSTART;TZID=Europe/Bucharest:20250520T071000
DTEND;TZID=Europe/Bucharest:20250520T072500

and that is correctly converted to UTC

  "start": "2025-05-20T04:10:00.000Z",

and adjusted from there, based on the MM timezone, and it appears correct LA/Chicago/NY/London/Berlin/Bucharest/Bangalore/Sydney

[Raducu-Alexandru]

When I imported the link to the ics file it it converted it to UTC+4, it was 11:10 instead of 10:10 (UTC+3), and after looking thru the code I saw that on the lines I mentioned above the function converts it from UTC to the event.tz which is UTC+2 (as in Brussels) and after that it tried to add 2 hours to it. The meeting is not created from Bucharest, but from Brussels. Because in the function getAdjustedStartMoment, you try this

let eventDiff = CalendarFetcherUtils.getTimezoneOffsetFromTimezone(event.end.tz);

which results in the value 2, because somehow the event.end.tz is UTC+2. I have the timezome correctly set and that is the exact event that I had troubles with, because the rest of them that are set directly in Google Calendar seem to have the event.end.tz misssing so it ignores it and it does not try and convert it, which just lets moment convert it automatically.

After I fixed the commented line in that function, it appeared correctly with 10:10.

[sdetweil]

i know what the code does, as i wrote it
i left the commented out part

we work off the ics file, whatever is exported from the calendar source

you can turn on debug logging

add

,"DEBUG"

to the loglevel property in config.js

npm start >somefile.txt

maybe you can capture a different view of the event
the one you presented works as expected

[Raducu-Alexandru]

Indeed, I successfully identified the issue by running the code in debug mode. I will attempt to run the code again and provide you with the specific section of the logs that also capture the

Log.debug(“startMoment post=“, startMoment);

Additionally, tomorrow, I will add some images of the calendar, both before and after the line change I made. I am also using a skin on the calendar that captures the broadcasted data, so there is no difference between what the native calendar shows and the CSS skin. Furthermore, I will interrogate the Pi to ensure that the timezone set in the UI is also the same in the Electron app with the DevTools enabled within Electron. I will return with the information, which may assist you in reproducing the issue.

[sdetweil]

cool.

[sdetweil]

I cannot reproduce this at all..

if the event is UTC, all ok, in all TZ (09:10 MM in brussels. 10:10 MM in bucharest)
if the event is Europe/Brussels(07:10) and MM is in Bucharest, all ok (event is shown as 08:10)
if the event is Europe/Bucharest(07:10) and MM is Brussels, all ok (event is shown as 06:10)

[Raducu-Alexandru]

Hi,

I am so sorry for not responding, and not keeping my promise of sending the info, but I just found out that next I will have a lot of tests/project presentations, and I won t really have the time right now. After I finish the next week I will come back and give you everything you need if you still want to go deeper and to try and reproduce the issue at your side as well. Thank you, and sorry again.

[sdetweil]

we have time. next release is july 1.