Incorrect time shown for recurring items

[counterpoint]

This can be verified by creating a calendar page and inserting the code: [fullcalendar icsfile="https://calendar.google.com/calendar/ical/pjb5747j5gn75hs223vms3bfng%40group.calendar.google.com/public/basic.ics"][/fullcalendar] This is a public calendar that should be accessible anywhere. There is an entry for a meeting at 7.30 pm on the second Wednesday of each month. Up to and including March 2021, it is shown correctly. From April 2021 onwards, it is shown incorrectly as 6.30 pm. This might be to do with the clock change on the last Sunday of March, although the time does not become correct again after the change is reversed on the last Sunday of October.

[ghost]

It's even weirder for me (in Australia). Up to March 2021 it shows the meeting at 6:30am on Thursday (prob 7:30pm day before in your time). But from April 2021 it jumps back to 9:30am on the Wednesday.

[counterpoint]

Correction. The entries that show correctly were individual entries. The recurring entry started in April 2021 and always shows one hour out, displaying as 6.30p whereas the calendar entry is for 19.30. Working from a Nextcloud calendar instead of Google gives correct time.

[counterpoint]

Thanks for your comment @simplycomputing. Looks as if you probably see the individual entries correctly, but strange that the recurring entry differs by a larger amount than it does for me.

[ghost]

Just tested this on my google calendar. I made a recurring test event at 9am and it shows on my website as 10pm - that is 10pm for every month into the future. So I don't think it's a daylight saving issue at all. Seems more like a time zone anomaly.

For you it is one hour out, but for me it is 11 hours.

[ghost]

But if I make a single event at 9am it shows correctly as 9am. So why is recurring treated differently??

[ghost]

@counterpoint - what is the time difference compared to UTC where you are? For me, Sydney NSW is 11 hours ahead of Coordinated Universal Time so I suspect the recurring events are not being localised.

[wernerjoss]

@simplycomputing , you are correct with your assumption that times for recurring events are currently not localized, see also the corresponding thread in the forum. meanwhile, I have found a version of the rrule.js library which is supposed to support timezones. I have already fiddled with this, and got it to display correct times for timzones Europe/London and Europe/Berlin, but not out-of-the box (had to add an offset, which seems strange to me). so, could you attach here an ics file with at least 1 recurring event for your timezone ?

[wernerjoss]

Correction. The entries that show correctly were individual entries. The recurring entry started in April 2021 and always shows one hour out, displaying as 6.30p whereas the calendar entry is for 19.30. Working from a Nextcloud calendar instead of Google gives correct time.

@counterpoint , can you provide an ICS file from Nextcloud (without private information) including a recurring event ?

[ghost]

Here is a google calendar ics. For me it has a recurring event at 12pm on the first day of the month, and a recurring event on 2nd Tuesday of the month at 9am cogginsalan@gmail.com.ical.zip .

[ghost]

My timezone is Sydney, Australia by the way. We are currently in daylight saving.

[wernerjoss]

thanks, Alan, a quick check with my current development state looks like this: which seems ok, so far. I'll do some more testing and then commit the changes to master, so you can check it out for yourself.

[ghost]

That looks good. But note the single test event has now jumped forward to previous day (should be 9am on the Wednesday).

[wernerjoss]

hm, looking into the ics file shows DTSTART:20211214T220000Z for the single event, which is Tuesday, 14th Dec. as shown. however, the screenshot shows 23pm, should be 22pm - strange. will have to do some more investigation, I guess :-)

[ghost]

Yes, sorry. I should have said the single test event has jumped back to the previous day. Here is how the calendar looks for me:

[wernerjoss]

ok, I see - but, the ics data you sent has the following entrys for that single event:

BEGIN:VEVENT DTSTART:20211214T220000Z DTEND:20211214T230000Z DTSTAMP:20211212T195632Z UID:69agtn00l5dakldt2ieh9fj9rm@google.com CREATED:20211210T042641Z DESCRIPTION:<a href="https://simplycomputing.com.au" id="ow745" __is_owner= "true">Link</a><br>This is a description.<br>It contains a link.<br><a href ="https://simplycomputing.com.au">https://simplycomputing.com.au</a> LAST-MODIFIED:20211210T052207Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:test event single TRANSP:OPAQUE END:VEVENT (the code display is badly formatted, line breaks are missing, sorry)

according to that, the day is tuesday 14th dec, not wednesday 15th dec. plus, your google calendar shows 9am as time, instead of 10pm. so, I guess, this could also be an UTC -> local time issue, as 10pm + 11h = 9am on next day. a possible explanation would be:

• single events data is stored as UTC
• recurring events data is stored using local date/time I'll see if this can be confirmed and how the plugin could deal with it.

[ghost]

Oh dear. This sounds like a nightmare to sort out! Well, if you want to just say that your plugin doesn't handle recurring events I certainly wouldn't blame you. :-)

[wernerjoss]

oh, well, I already thought about that, yes :smile: - but I have meanwhile put so much time into this, I want it to get going, finally. it seems now I had to add even more javascript stuff for timezone handling, and it looks like I'm on the right way, now: this is only an intermediate result with some things hard coded, but, at least, I guess it will work out. I'll see how long that will take...

[wernerjoss]

so, I have committed my latest improvements to master, which works for my Test cases here. I had to use 2 different javascript librarys with integrated timezone support, one for single events, one for recurring events. unfortunately, both libs do not exactly work the same way, so additional adaptions were necessary. can you check if this works for you ?

[ghost]

No, sorry to report not working. I created a new recurring event 6am every Wednesday. This is the google calendar compared to the grav calendar. As you can see both recurring and single are both out.

[wernerjoss]

ok, can you attach the ics file, please ?

[ghost]

Here it is. cogginsalan@gmail.com.ical.zip

[wernerjoss]

thanks, this looks ok here: maybe you did not clear the grav cache before loading the calendar ? (and , to be sure, also clear the browser cache)

[ghost]

I cleared the cache numerous times, and tried it on a different browser (also cleared that). Still the same. Does the timezone in the Grav settings affect this? I have mine set to Sydney, Australia. What is yours?

[ghost]

Hmmm... this is getting crazy. If I put that ICS file in as a straight file calendar then I get this:

[wernerjoss]

well, I also thought about the grav config timezone setting, mine is Europe/Berlin, then I also tried Australia/Sydney: no difference (as expected). it looks to me as if you have still the old plugin version. you can check this in your admin backend, under plugins. fullcalendar should report v0.2.14 - if it shows 0.2.13, you still have the old version.

[ghost]

[wernerjoss]

hm, that seems ok. so, I'm afraid I'm out of ideas, currently - sorry. will think about this later on....

[ghost]

Yeah. It seems like a mess of complications. Thanks for trying.

[wernerjoss]

after some more investigation, I have now the impression that the timezone related javascript libs are just not working for you, although I have no clue why. they should be visible in the javascript debugger like so: can you confirm this ?

[ghost]

Will check that.

I also think it is odd that I get different result when using the calendar link to when I put in the ics file. If you want to test this the direct link is: https://calendar.google.com/calendar/ical/cogginsalan%40gmail.com/public/basic.ics

[ghost]

OK - found it. I have this

[wernerjoss]

yes, that is the right view - the js debugger is sometimes called Sources. so, the relevant libraries show up to be loaded, which makes the whole thing even more obscure, as they obviously do not seem to work for you. as for the difference calendar link <-> ics file I will check tomorrow.

[counterpoint]

The calendar file I have been testing with is publicly available at https://thirskandmalton.greenparty.org.uk/calendar.ics. It displays correctly at https://thirskandmalton.greenparty.org.uk/calendar/ and is served by Nextcloud.

[counterpoint]

You can see the Full Calendar display connected to Nextcloud and also connected to Google at https://calendar.bsr.cloud/. Curiously, the results are different. It appears that the recurring entry that is based on a fixed recurring date (Green Drinks on 5th of every month) displays correctly when feed from Nextcloud but not from Google. Whereas the recurring event based on the second Wednesday of each month (T&M GP Monthly Meeting) displays wrong in both.

[wernerjoss]

The calendar file I have been testing with is publicly available at https://thirskandmalton.greenparty.org.uk/calendar.ics. It displays correctly at https://thirskandmalton.greenparty.org.uk/calendar/ and is served by Nextcloud.

@counterpoint , I have now made some more investigations into this and it looks like the timezone librarys mentioned above are not aware if the month of the event's start date is within or out of the daylight saving time. so, I guess I will have to determine that from the ics file, as this has a VTIMEZONE block with rules for daylight saving and for standard time. my understanding so far was the timezone libs would handle that automatically, but they do not. I'll work on that issue now, but no guarantee how long a solution will take :smile:

[counterpoint]

Thanks @wernerjoss. It seems that the need for Javascript to produce a pretty calendar is throwing up a lot of issues. I was very disappointed that you closed the issue that the popups cannot be moused over. It's not just a matter of not being able to click on links (although that is certainly desirable), it's that you cannot even copy and paste them. If you are reliant on Javascript libraries, it's probably no help to you, but the PHP libraries used in your iCalendar plugin seem to work fine. I added some code to that plugin to pick out any weblinks in the event description, and also made location into a link to Google maps. And elaborated the display a little. The result can be seen at https://calendar.bsr.cloud/events-ical. It isn't as cute as a calendar, but it is a lot more functional. If the calendar can't be made to (a) show correct times and (b) allow for people to link to further information on events, I'm likely to use the event list for preference. I'll probably add a bit more code to fetch the ICS file dynamically (rather than with cron etc).

[wernerjoss]

well, the icalendar plugin is just a simple list, not more. everything that is more visually appealing, is nowadays based on javascript, or even on heavy librarys built upon it, like react. if you like to share your icalendar modifications, you could just make a fork and publish that, evtl. including a pull request. as for the rest, yes, I plan to get the timezone (incl. recurring events) issue resolved.

[counterpoint]

@wernerjoss Yes, I appreciate it is "just" a simple list. But the purpose of a calendar is for people to see what events are planned, and to gain access to details in a useful way. I'm grateful for your efforts on the time problem, but at present the calendar is unusable as it displays incorrect times. Beyond that, from my point of view, a "simple" list that provides all the details of forthcoming events, including clickable links for online meetings or locations or whatever is a lot more user friendly than a calendar that doesn't provide those features. Yes, I'd use a calendar if one with the ICS Calendar functionality was available. But in its absence, my extended event list meets user requirements better. I will try to fork etc when time permits, although as a novice Grav developer I've yet to figure out whether it ought to work like iCalendar or should create its own template, or whether there are any other alternatives for a plugin. To be generally useful, I guess the styling should be parameterised too. BTW I've added the day of the week to each item now.

[wernerjoss]

ok, @counterpoint , then lets just see what your and my improvements will lead to :smile: - also note it is easy to make a calendar page which combines fullcalendar and icalendar, e.g. icalendar using an accordion, thus it initially only occupies one line (which is easy to unfold and see the complete list).

[wernerjoss]

so, finally, I'm back again with some news w.r to this issue, see the updated docs - Timezone issues. unfortunately, as said there, I could not find an automatic solution. but, with the now available tz_offset* settings, it should be possible to correctly display calendars from different timezones. e.g., this calendar works for me using the settings on the screenshot: also note there is now a new setting for onClick Popups which will, if enabled, create a simple alert() window showing the event description, which is ugly, but, at least, text can be copied from :smile:

[ghost]

Fantastic! That is an ideal solution since there seem to be so many variables. I'll test it out when I get a chance.

Thanks for all your work on this and Happy New Year!

[ghost]

This is getting very close, but there is one little bug I found. If I use these settings...

I found I can get my calendar perfectly in sync with my Google calendar times. This is now all correct:

That's great. But I was testing what happened when I changed the single event setting. It actually affects both single and recurring.

So this is the result. You see the single has correctly moved on 2 hours, but also the recurring has moved as well.

[ghost]

Actually, it's not really much of a bug. I can get them changed any way I want by adjusting both values. So this will work:

You could always "fix" it by just changing the text on the first field to "Time Offset (hours) to correct all Events" :-)

Nice work!

[wernerjoss]

ok, fine to see it is now working for you, too. and, yes, corrections are not independent, the single events offset will also affect the recurring events, so, single should be adjusted first, then see what happens to recurring events and then correct those. I'll update the docs accordingly.

[ghost]

Ah, good. Then it's working perfectly. You just need to clarify that in the docs (and maybe the field name).

I think it's an excellent solution! It seemed like a nightmare trying to adjust your code to cater for every calendar and time handling. But this is simple and elegant.

[wernerjoss]

well, I still think this solution is not ideal, as would be an automatic adjustment, but, at least, I hope it can solve the timezone Problem for most users. and, as the corrections will have to be done only once, it is not a big effort, nor an ongoing one. I think I will now improve the docs some more and then make a new release. and thanks again for your patience during these iterations :smile:

[wernerjoss]

I'm closing this now as there have been no more comments/reports.

[s1-ranjan]

@wernerjoss, as of now the only support for the hour part is been implemented to this plugin, can this plugin be extended for the minutes too, as I am located in the +5.30 time zone and this plugin is not showing the correct event timing in the calander.

[wernerjoss]

hi @s1-ranjan - yes, the plugin does currently only support integer hour values for timezone corrections. I'll look into this and see how at least 30 minutes intervals can be implemented (I don't think 1 minute steps will be necessary, I have never seen timezones that have other fractions than 30 minutes offset to UTC)

[s1-ranjan]

Thanks, @wernerjoss for writing me, I would like to point out for Nepal time zone cause Nepal is having +5:45 hours offset, so it would be better to give a better fix so that this plugin has a better fix for everybody.