same problem here

Kugelfang666 on 1 Nov 2019

same here in PST

snarksandrec on 4 Nov 2019

The calendar module is using moment, and I believe that may be where the issue is coming from. I found a similar issue Brazil users are facing. https://github.com/MichMich/MagicMirror/issues/1568 may help you out as well.

georgeglessner on 4 Nov 2019

same here

edit the quick fix #1568 wont resolve the problem

derKaY on 5 Nov 2019

Same issue observed here as well. The issue presents itself on some third party calendar modules I tested as well.

Issue is occurring on two separate mirrors.

jsndyr on 5 Nov 2019

Same here. Shift from summer time to winter time results in recurring events show up one hour too early.

thyed on 6 Nov 2019

Can this be related to #1803 ?

henry2man on 7 Nov 2019

It seems that everyone is referencing other post and it has become a circular post.

37 1803

and this one are all related.
Along with this forum post: https://forum.magicmirror.builders/topic/9039/mmm-calendarweek/2?page=1

Is there a fix for this yer?

Lotusvball on 8 Nov 2019

It is also present when a repeating event crosses time change date (for example change from standard time to daylight savings time)

kfksee on 24 Nov 2019

Same problem here.

LeGro88 on 9 Jan 2020

After deleting the calendar files and downloading them again, the calendar now works fine for me.

Do you mean the source files or the files that the module downloads from the calendar app (e.g. Google Calendar)?

secastles on 15 Jan 2020

PR #1884 submitted for a possible fix to this. My wife and I were having this same issue on our calendar and were able to fix ours with this workaround. Would welcome any comments / further testing on it to see if it fixes yours as well.

kblankenship1989 on 18 Jan 2020

Merged your commit (ignore the accidental revert notification). Hope this solves the issue.

MichMich on 18 Jan 2020

👍1

I still encounter problems with the latest version. rolling back the calendar module to the one from 2.7.1 fixes this problem for me

Kugelfang666 on 28 Jan 2020

I still encounter problems with the latest version. rolling back the calendar module to the one from 2.7.1 fixes this problem for me

@Kugelfang666 is it the same issue listed above or a different one? There was a comment on my PR that I missed "month +1" so I am putting that fix up now so it may just be that we are off by a month. can you share an example of what you are seeing right now (snap shot / test ics that I can use to verify against, or the following details:

start time of event
recurrance
timezone you are in
what you are currently seeing and what you expect to see)

Thanks for any help you can provide to further troubleshoot

kblankenship1989 on 31 Jan 2020

@kblankenship1989 i was refearing to t he issue where full day events are shown one day late. If I'm not mistaken this was related to the original -1h bug that causes full day events to be moved

Kugelfang666 on 31 Jan 2020

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.

stale[bot] on 31 Mar 2020

well it again occurs, I have the feeling that this always happens around daytime shift and after a while dissipates again

Kugelfang666 on 31 Mar 2020

Yes, seeing this too. I have an event which is in my google calendar at 9am PST, I'm the the UK so at UTC+1, and it shows up in the mirror as 9am instead of 5pm.

rossburton on 18 May 2020

Yes, seeing this too. I have an event which is in my google calendar at 9am PST, I'm the the UK so at UTC+1, and it shows up in the mirror as 9am instead of 5pm.

Hey guys, sorry for the delay in responding. Looks like I had missed a -1 and the PR never got submitted. I am testing this locally on our instance as we had a couple of evens that shifted as well, and will hopefully have the updated PR up this weekend to get it in. Again sorry for the delay.

kblankenship1989 on 19 May 2020

@kblankenship1989 - have you been able to get the fix in for this issue?

chamakura on 14 Jun 2020

@kblankenship1989 - have you been able to get the fix in for this issue?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

dish67 on 14 Jun 2020

@chamakura @dish67 sorry for the delay in response. I looked and it appears my PR was merged into Master on the last release. Are you using the latest release from 4/1 and still seeing this issue?

kblankenship1989 on 17 Jun 2020

@kblankenship1989 Not a problem! I'm actually still seeing an issue, but probably it's different than what you've fixed. Here's what I'm seeing:

I'm in PDT (GMT-7)
A colleague of mine in EDT (GMT-4) sets up a meeting for 1 p.m. PDT (=4 p.m. EDT)
The event shows up on my Calendar for 4 p.m. PDT (local time)

To me, it looks like the issue is that we're assuming all events originate in the local timezone - I couldn't find any code that's handling the timezone of the startdate while parsing the VCAL entries.

For now I have applied a local patch to adjust the time based on the timezone which is used in startdate. When I have time I'll try to figure out a way to handle this in a generic manner and submit a fix, but it would be great if you can figure it out.

chamakura on 17 Jun 2020

Hi all people struggling with this bug. I added a hack that fixed it for my particular case. Just a few lines of code in calendar.js. Please test it out and see if it helps for you too?

wolfen351 on 27 Jun 2020

Here is the pull request showing the lines that need to be added: https://github.com/MichMich/MagicMirror/pull/2057

This causes the calendar data no longer to be interpreted as UTC, but rather in local time.

wolfen351 on 27 Jun 2020

PR merged into develop.

MichMich on 4 Jul 2020

Let me know if I need to reopen this issue.

MichMich on 4 Jul 2020

I am new to MagicMirror and unfamiliar with many of the libraries etc. so sorry if I am no help, but the section of code that references this issue causes my recurring appointments to be off by 4 hours. When I comment out the datesLocal.map portion and just do const dates = datesLocal. It works as intended.

Here's the desired start date (without the mapping): Sun Aug 30 2020 09:30:00 GMT-0400 (Eastern Daylight Time)
Here's what it shows (with the mapping): Sun Aug 30 2020 13:30:00 GMT-0400 (Eastern Daylight Time)

scottdrichards on 29 Aug 2020

what are the cal timezone and start and end dates in the ics for this cal entry u are showing.

sdetweil on 29 Aug 2020

On Outlook it lists the time zone as (UTC-05:00) Eastern Time with start date being: 3/22/2020 with no end date.

The event object is as follows:
event:

{type: 'VEVENT', params: Array(0), rrule: RRule, exdate: Array(0), uid: '....'}
class: 'PUBLIC'
dtstamp: Sat Aug 29 2020 10:20:08 GMT-0400 (Eastern Daylight Time)
end: Sun May 31 2020 10:30:00 GMT-0400 (Eastern Daylight Time)
exdate: (0) [2020-08-09: Sun Aug 09 2020 09:30:00 GMT-0400 (Eastern Daylight Time)]
2020-08-09: Sun Aug 09 2020 09:30:00 GMT-0400 (Eastern Daylight Time)
length: 0
__proto__: Array(0)
location: ''
MICROSOFT-CDO-ALLDAYEVENT: 'FALSE'
MICROSOFT-CDO-APPT-SEQUENCE: '0'
MICROSOFT-CDO-BUSYSTATUS: 'BUSY'
MICROSOFT-CDO-IMPORTANCE: '1'
MICROSOFT-CDO-INSTTYPE: '1'
MICROSOFT-CDO-INTENDEDSTATUS: 'BUSY'
MICROSOFT-DISALLOW-COUNTER: 'FALSE'
MICROSOFT-DONOTFORWARDMEETING: 'FALSE'
params: (0) []
priority: '5'
rrule: RRule {_string: null, _cache: Cache, origOptions: {…}, options: {…}, timeset: Array(1)}
sequence: '0'
start: Sun May 31 2020 09:30:00 GMT-0400 (Eastern Daylight Time)
status: 'CONFIRMED'
summary: '[personal]'
transparency: 'OPAQUE'
type: 'VEVENT'
uid: '...'

And the rrule object is:

event.rrule
RRule {_string: null, _cache: Cache, origOptions: {…}, options: {…}, timeset: Array(1)}
_cache: Cache {all: false, before: Array(0), after: Array(0), between: Array(0)}
_len: 40
_string: null
options: {freq: 2, until: Sun Feb 28 2021 09:30:00 GMT-0500 (Eastern Standard Time), interval: 1, byweekday: Array(1), wkst: 0}
origOptions: {freq: 2, until: Sun Feb 28 2021 09:30:00 GMT-0500 (Eastern Standard Time), interval: 1, byweekday: Array(1), wkst: Weekday}
timeset: (1) [Time]

scottdrichards on 29 Aug 2020

really want to see the text in the ics file. not what outlook shows. also the timezone of the cal itself. which may be different from the system timezone

sdetweil on 29 Aug 2020

Makes sense, hopefully this helps!

BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
X-WR-CALNAME:Calendar
BEGIN:VTIMEZONE
TZID:Customized Time Zone
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Mountain Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

Here's the event:

BEGIN:VEVENT
RRULE:FREQ=WEEKLY;UNTIL=20210228T143000Z;INTERVAL=1;BYDAY=SU;WKST=MO
EXDATE;TZID=Customized Time Zone:20200809T093000
UID:040000008200E00074C5B7101A82E00800000000FD5C91A7DEFFD501000000000000000
 0100000008B41104F2B6364498B657AD77195984F
SUMMARY:[Personal]
DTSTART;TZID=Customized Time Zone:20200531T093000
DTEND;TZID=Customized Time Zone:20200531T103000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200829T150518Z
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
END:VEVENT

scottdrichards on 29 Aug 2020

I don't see anywhere in the data this start date

On Outlook it lists the time zone as (UTC-05:00) Eastern Time with start date being: 3/22/2020 with no end date.

I see 5/31/2020
DTSTART;TZID=Customized Time Zone:20200531T093000
DTEND;TZID=Customized Time Zone:20200531T103000

and the rule (except for) exdate 08/09/2020
EXDATE;TZID=Customized Time Zone:20200809T093000
and
repeats until 20210228T143000Z
02/28/2021 (utc)

i look at my calendar, (google) and it sets its timezone

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:[email protected]
X-WR-TIMEZONE:America/Chicago

then defines the timezones

BEGIN:VTIMEZONE
TZID:America/Chicago
X-LIC-LOCATION:America/Chicago
BEGIN:DAYLIGHT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
TZNAME:CDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
TZNAME:CST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE

and my events are all in UTC time

BEGIN:VEVENT
DTSTART:20200618T161500Z
DTEND:20200618T171500Z
DTSTAMP:20200602T120315Z
UID:6hh3ip9n6kr3cb9jchh62b9kchhj8b9p6sq34b9k71im2chicdj38chn74@google.com
CREATED:20191218T173501Z
DESCRIPTION:
LAST-MODIFIED:20200527T134112Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Doctor 
TRANSP:OPAQUE
END:VEVENT

looking at the node-ical code, it doesn't seem to handle the 'Customized Time Zone' type
assumes date is in local computer timezone. and calendar doesn't specify its timezone base.
BEGIN:VTIMEZONE
TZID:Customized Time Zone
altho is does list the regional daylight/standard attributes
but all the daylight/standard in there use the same weird date/time value
DTSTART:16010101T020000

i don't know how one would figure out what any time adjustment should be

sdetweil on 29 Aug 2020

So, I'm experiencing the same issue with recurring Google Calendar events display hours after they should but single events display correctly
. MM2 shows 4 hours after actual. Inserted the suggested calendar.js on line 470. Now those appointments are showing even later and other appointments (that were correct before) are off as well. // the new code out returns recurring appointments to the 4 hours display error and non-recurring ones are displaying correctly.

The only conflict I can see is the Google Calendar TimeZone is Eastern Time-New York and the Raspberry PI4 is Set to America-New York

RJDaPirate on 29 Aug 2020

I don't see anywhere in the data this start date
On Outlook it lists the time zone as (UTC-05:00) Eastern Time with start date being: 3/22/2020 with no end date.
I see 5/31/2020
DTSTART;TZID=Customized Time Zone:20200531T093000
DTEND;TZID=Customized Time Zone:20200531T103000

and the rule (except for) exdate 08/09/2020
EXDATE;TZID=Customized Time Zone:20200809T093000
and
repeats until 20210228T143000Z
02/28/2021 (utc)

i look at my calendar, (google) and it sets its timezone

....

i don't know how one would figure out what any time adjustment should be

I'll look into it more, it's coming from a Microsoft calendar so maybe they format their entries differently. This is also the first time I've ever looked into an iCal file, so I may have missed something.

scottdrichards on 31 Aug 2020

Here's a more complete section of the iCal file:

BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
X-WR-CALNAME:Calendar
BEGIN:VTIMEZONE
TZID:Customized Time Zone
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DESCRIPTION:[private]
RRULE:FREQ=WEEKLY;UNTIL=20201217T153500Z;INTERVAL=1;BYDAY=TU,TH;WKST=SU
UID:1173422081SZR322
SUMMARY:[private]
DTSTART;TZID=Customized Time Zone:20200825T103500
DTEND;TZID=Customized Time Zone:20200825T115000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200901T175645Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION: [private]
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
END:VEVENT
END:VCALENDAR

scottdrichards on 1 Sep 2020

@scottdrichards thanks for the ics, when the code returns from parsing the ics, it is already broken

event={"type":"VEVENT","params":[],"description":"[private]","rrule":{"_string":null,"_cache":{"all":false,"before":[],"after":[],"between":[]},"origOptions":{"freq":2,"until":"2020-12-17T15:35:00.000Z","interval":1,"byweekday":[{"weekday":1},{"weekday":3}],"wkst":{"weekday":6},"dtstart":"2020-08-25T09:35:00.000Z"},"options":{"freq":2,"until":"2020-12-17T15:35:00.000Z","interval":1,"byweekday":[1,3],"wkst":6,"dtstart":"2020-08-25T09:35:00.000Z","count":null,"tzid":null,"bysetpos":null,"bymonth":null,"bymonthday":[],"bynmonthday":[],"byyearday":null,"byweekno":null,"bynweekday":null,"byhour":[9],"byminute":[35],"bysecond":[0],"byeaster":null},"timeset":[{"hour":9,"minute":35,"second":0,"millisecond":0}]},"uid":"1173422081SZR322","summary":"[private]","start":"2020-08-25T09:35:00.000Z","end":"2020-08-25T10:50:00.000Z","class":"PUBLIC","priority":"5","dtstamp":"2020-09-01T17:56:45.000Z","transparency":"OPAQUE","status":"CONFIRMED","sequence":"0","location":" [private]","MICROSOFT-CDO-APPT-SEQUENCE":"0","MICROSOFT-CDO-BUSYSTATUS":"BUSY","MICROSOFT-CDO-INTENDEDSTATUS":"BUSY","MICROSOFT-CDO-ALLDAYEVENT":"FALSE","MICROSOFT-CDO-IMPORTANCE":"1","MICROSOFT-CDO-INSTTYPE":"1","MICROSOFT-DONOTFORWARDMEETING":"FALSE","MICROSOFT-DISALLOW-COUNTER":"FALSE"}

the start, end and dtstart have the right day, but wrong time and timezone.

I have opened issue with the ical library
https://github.com/jens-maus/node-ical/issues/13

sdetweil on 1 Sep 2020

🎉1

@MichMich can we reopen this, or should a make another based on the iCal problem

sdetweil on 3 Sep 2020

Reopened

MichMich on 3 Sep 2020

Hi,
Just my 2 cents in case it might help.
I was having the same issue: all days recurring event were displaying one day early (Sept 12th instead of Sept 13th). I switched to develop branch (to fix something unrelated, ie Forecast only displaying 2 days) and the issue is gone.

rbouhet on 9 Sep 2020

Same here - here a example ical from Google calender.

The calandar - wich is a series entry - is showed on the magicmirror at 09:45 not at the correct time at 11:45

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20200917T114500
DTSTAMP:20200909T110833Z
RECURRENCE-ID;TZID=Europe/Berlin:20200917T114500
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GGS: Ende
TRANSP:OPAQUE
END:VEVENT

pi@magicmirror:~/MagicMirror/config $ timedatectl
      Local time: Mi 2020-09-09 13:12:13 CEST
  Universal time: Mi 2020-09-09 11:12:13 UTC
        RTC time: n/a
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

kleinmantara on 9 Sep 2020

Are you willing to help this NOOB do the same? Can you provide a step by
step?
Thank you and have a wonderful day,
Ryan Jones
443-801-1974

On Wed, Sep 9, 2020 at 3:56 AM rbouhet notifications@github.com wrote:

Hi,
Just my 2 cents in case it might help.
I was having the same issue: all days recurring event were displaying one
day early (Sept 12th instead of Sept 13th). I switched to develop branch
(to fix something unrelated, ie Forecast only displaying 2 days) and the
issue is gone.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MichMich/MagicMirror/issues/1798#issuecomment-689391329,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZO3NQUT3XZTHHC6LCFZXLSE4YKBANCNFSM4JG7OOEA
.

RJDaPirate on 9 Sep 2020

Are you willing to help this NOOB do the same? Can you provide a step by step? Thank you and have a wonderful day, Ryan Jones 443-801-1974
…
On Wed, Sep 9, 2020 at 3:56 AM rbouhet @.*> wrote: Hi, Just my 2 cents in case it might help. I was having the same issue: all days recurring event were displaying one day early (Sept 12th instead of Sept 13th). I switched to develop branch (to fix something unrelated, ie Forecast only displaying 2 days) and the issue is gone. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1798 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQZO3NQUT3XZTHHC6LCFZXLSE4YKBANCNFSM4JG7OOEA .

Simply go to your MagicMirror folder in command line and checkout develop branch (the git pull might be unnecessary):
cd MagicMirror
git checkout develop

rbouhet on 9 Sep 2020

I don't know if it's the same issue or not: I work in an international company, I'm based in CET Time Zone and some people I work with are based in PST Time Zone.
The entries I set up are showing ok (ie correct date/time), however entries set up by PST people display using PST Date/Time and are not converted to my time zone, so their time appears wrong.
Entries in ics file are like this:
CET:

DTSTART;TZID=W. Europe Standard Time:20200915T083000
DTEND;TZID=W. Europe Standard Time:20200915T093000

PST:

DTSTART;TZID=Pacific Standard Time:20200915T083000
DTEND;TZID=Pacific Standard Time:20200915T093000

I would expect the PST meeting to display "2020-09-15 17:30" but it shows up as "2020-09-15 08:30".
Am I missing something ?
Thanks

rbouhet on 9 Sep 2020

@rbouhet have u tried the develop branch yet, there are fixes for the calendar problem

sdetweil on 9 Sep 2020

@sdetweil yes, I'm on develop branch,
It fixed the issue I had on recurring google events.

The issue I just mentionned probably has a different root since it applies to both recurring and non recurring events.
I think the parsing of dates simply does not take into account the TZID part of dates from the ics, is that possible ?

rbouhet on 9 Sep 2020

I had submitted a fix related to the TZID parsing issue a while ago, but it hasn't been approved: https://github.com/MichMich/MagicMirror/pull/2086

chamakura on 9 Sep 2020

@rbouhet there was a fix for this included when I fixed the recurring not showing today problem (2121). when did u switch to develop?

try a git pull to update

there IS a problem still with ics rrule parsing in general, and why I had this issue reopened.

if u have a little ics file with header and the one event, I can add it to the ics problem

sdetweil on 9 Sep 2020

@sdetweil git pull says I'm already up to date.
I actually installed magic mirror only yesterday, still new to it.

The ics file is my profesional calendar so I don't feel like sharing it completely is a good idea, but I can give you snippets if you want.
These display correctly:

BEGIN:VEVENT
DESCRIPTION:\n
UID:040000008200E00074C5B7101A82E0080000000070DE40F38786D601000000000000000
 010000000D2A9BA8A3668CA4ABB2CC6838268179F
SUMMARY:test
DTSTART;TZID=W. Europe Standard Time:20200910T090000
DTEND;TZID=W. Europe Standard Time:20200910T093000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200909T160350Z
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:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
BEGIN:VEVENT
DESCRIPTION:\n
RRULE:FREQ=WEEKLY;UNTIL=20210309T080000Z;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR;WK
 ST=MO
UID:040000008200E00074C5B7101A82E008000000008001F1896B63D301000000000000000
 0100000005D0552D848712746896D6C8E2E066560
SUMMARY:Log Yesterday's Jira time
DTSTART;TZID=W. Europe Standard Time:20200609T090000
DTEND;TZID=W. Europe Standard Time:20200609T093000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200909T112410Z
TRANSP:TRANSPARENT
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:FREE
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
END:VEVENT

Not these:

BEGIN:VEVENT
UID:040000008200E00074C5B7101A82E008000000007070639B9D82D601000000000000000
 010000000690B7C3173632247A60664DDD8E0160E
SUMMARY:Not the actual summary
DTSTART;TZID=Pacific Standard Time:20200915T083000
DTEND;TZID=Pacific Standard Time:20200915T093000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200909T112410Z
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:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT

BEGIN:VEVENT
RRULE:FREQ=WEEKLY;UNTIL=20210309T200000Z;INTERVAL=1;BYDAY=TU,TH;WKST=SU
EXDATE;TZID=Pacific Standard Time:20200721T120000,20200723T120000,20200728T
 120000,20200813T120000,20200825T120000,20200903T120000
UID:040000008200E00074C5B7101A82E00800000000C8CF296B9654D601000000000000000
 01000000031C6A267A9E4A2489CEB57D709E7A37F
SUMMARY:Not the actual summary either
DTSTART;TZID=Pacific Standard Time:20200707T120000
DTEND;TZID=Pacific Standard Time:20200707T123000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20200909T112410Z
TRANSP:TRANSPARENT
STATUS:CONFIRMED
SEQUENCE:3
LOCATION:https://bluejeans.com/7999979999
X-MICROSOFT-CDO-APPT-SEQUENCE:3
X-MICROSOFT-CDO-BUSYSTATUS:FREE
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
END:VEVENT

When I mean "not correctly", I mean I would expect them to be converted to local time. Here it just seems that TZID is just ignored.
Maybe my config is wrong ?

{
            module: "calendar",
            header: "meetings",
            position: "top_left",
            config: {
                timeFormat: "absolute",
                maximum: 100,
                excludedEvents: ['ooo'],
                //maximumNumberOfDays: 2,
                getRelative:0,
                urgency: 0,
                fullDayEventDateFormat: "DD/MM",
                dateFormat:"DD/MM hh:mm",
                showEnd:false,
                hideOngoing:true,
                calendars: [
                    {
                        symbol: "calendar-check-o",
                        url: "here is my calendar url",
                    }
                ]
            }
        },

rbouhet on 9 Sep 2020

@rbouhet could u share the calendar header? u can change the text, just not the time and timezone info. that way I can debug it

see the calendar def here https://github.com/MichMich/MagicMirror/issues/1798#issuecomment-683303030
looking for similar

sdetweil on 9 Sep 2020

Here is the header (looking at it looks pretty messy? Thanks Office I guess....)

header.txt

rbouhet on 9 Sep 2020

@rbouhet did u switch to the develop branch? i have tested and don't see anything wrong.. 08:45(ish) US CDT

https://www.dropbox.com/s/wmynah0n7lfwaxl/Screenshot_2020-09-10_08-52-04.png?dl=0

sdetweil on 10 Sep 2020

@sdetweil I switched yesterday (am I suppsoed to npm install again after switching though ?)
Note on your screenshot the "Log Yesterday's Jira time" is 9AM CET, so in US CDT I wouldn't expect it to display at 9AM but 2AM since that's when the "meeting" is actually taking place.

Here is the time displayed on my side and in red the actual time of the meeting. The CET ones are displayed correctly, but I would expect the PST ones to be converted to CET since that's my time zone.

rbouhet on 11 Sep 2020

no need to npm install, you did that already.

ok, still fighting the ics parser library ( not our code) which is returning the event date as local time, using the existing numbers. (it's supposed to return utc time)

sdetweil on 11 Sep 2020

Work life finally got out of my way and I could return to my MagicMirror Project. I can now confirm the fix of Recurring Events time errors and a single day weather forecast is successful.

I used an used the installation script (to install MM2). Here is the fix code. Url provided below.

cd ~/Magicmirror
rm package-lock.json
git fetch origin develop:develop
git checkout develop

https://forum.magicmirror.builders/topic/13575/2-12-repeating-all-day-calendar-events-not-shown-for-today-or-weather-only-showing-2-days-and-missing-analog-clock-numbers

Thank you for your help and guidance.

RJDaPirate on 13 Sep 2020

@rbouhet I want to make sure that I am testing correctly.. the tz listed is "W. European Standard Time", NOT CET

I added a lookup to the standard ical libs, which will translate from the MS TZ names to the IANA TZ names used everywhere else and by the javascript libs. there may be multiple locations which map to the same MS TZ name.. , for example

<!-- (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna -->
            <mapZone other="W. Europe Standard Time" territory="001" type="Europe/Berlin"/>
            <mapZone other="W. Europe Standard Time" territory="AD" type="Europe/Andorra"/>
            <mapZone other="W. Europe Standard Time" territory="AT" type="Europe/Vienna"/>
            <mapZone other="W. Europe Standard Time" territory="CH" type="Europe/Zurich"/>
            <mapZone other="W. Europe Standard Time" territory="DE" type="Europe/Berlin Europe/Busingen"/>
            <mapZone other="W. Europe Standard Time" territory="GI" type="Europe/Gibraltar"/>
            <mapZone other="W. Europe Standard Time" territory="IT" type="Europe/Rome"/>
            <mapZone other="W. Europe Standard Time" territory="LI" type="Europe/Vaduz"/>
            <mapZone other="W. Europe Standard Time" territory="LU" type="Europe/Luxembourg"/>
            <mapZone other="W. Europe Standard Time" territory="MC" type="Europe/Monaco"/>
            <mapZone other="W. Europe Standard Time" territory="MT" type="Europe/Malta"/>
            <mapZone other="W. Europe Standard Time" territory="NL" type="Europe/Amsterdam"/>
            <mapZone other="W. Europe Standard Time" territory="NO" type="Europe/Oslo"/>
            <mapZone other="W. Europe Standard Time" territory="SE" type="Europe/Stockholm"/>
            <mapZone other="W. Europe Standard Time" territory="SJ" type="Arctic/Longyearbyen"/>
            <mapZone other="W. Europe Standard Time" territory="SM" type="Europe/San_Marino"/>
            <mapZone other="W. Europe Standard Time" territory="VA" type="Europe/Vatican"/>

to simplify the mapping I take the 1st entry in the list as the IANA tz to use, which makes the adjustment to my current timezone 7 hours,
berlin (+2) to US CST (-5)
https://raw.githubusercontent.com/unicode-org/cldr/master/common/supplemental/windowsZones.xml, which should correctly adjust those to 2am US CST..

is that correct?

sdetweil on 13 Sep 2020

@rbouhet I have a test fix... I submitted support to the ical.js and node-ical projects

but u can test like this

cd ~/MagicMirror/node_modules
mv ical old_ical
git clone https://github.com/sdetweil/ical.js.git ical
cd ical
npm install

then run MM like normal

sdetweil on 14 Sep 2020

@MichMich

I see that Peter (ical) author states that his module is intended for in browser, and as such has no fs access.
https://github.com/peterbraden/ical.js/pull/111, comment 2

I think we need to move to node-ical, which doesn't have this limitation. (stated in it readme)
I added the same fixes there, it takes one change to the fetcher to change the library name in the require()
I am testing, so far so good.. I will submit a pr to take node_ical from my repo til the fix is approved and merged in node_ical and published.

sdetweil on 15 Sep 2020

Hi @sdetweil ,
I finally managed to get back to my Smart Mirror project.
Your change on node-ical does the trick and I am now seeing the time converted to my time zone as I would expect:

And I can confirm this works for both recurring and non recurring meetings.

rbouhet on 15 Sep 2020

@rbouhet great! thanks for the feedback. which module did u test, ical.js or node-ical?

sdetweil on 15 Sep 2020

@rbouhet I have a test fix... I submitted support to the ical.js and node-ical projects

but u can test like this
cd ~/MagicMirror/node_modules
mv ical old_ical
git clone https://github.com/sdetweil/ical.js.git ical
cd ical
npm install
then run MM like normal

@sdetweil This is the one I used

rbouhet on 15 Sep 2020

@rbouhet thanks. that's the ical.js module, altho u said node-ical.. just making sure we are in synch..

thanks again

sdetweil on 15 Sep 2020

this issue can be closed

sdetweil on 22 Sep 2020

Thank you so much @sdetweil for fixing this! I recently added the family calendar on our mirror and these recurring events have not worked properly before now (the timezone issue). After updating to latest it's working perfectly!

ZakarFin on 6 Oct 2020

Magicmirror: Timeshift calendar issue / Recurring Google Calendar events for times when UTC date differ from local date appear at wrong time in MM

All 65 comments

37

1803

Related issues