Calendar all day events start 02:00 end 02:00
-
Is nobody else getting this issue, it seems like a pretty major bug to me?
It would be great to know where the times for the All Day Event are configured.
/usr/share/kopano-webapp/client/kopano.js seems to control all this and I think it might be due to the commonstart and commonend variable lookups but I have no idea where this is set.
-
@nanathlor thats 02:00 = UTC, which is… CET +2
i suggest, verify verithing timezone related.
if these are all correct, well, then you found a bug. -
Hi
Nice idea:
Debian timedatectl shows Europe/London
php.ini = Europe/London
/etc/kopano/webapp/config.php = Europe/LondonMy calendar all-day appointments get set for 0:00 to 1:00 and show as 1 day in my calendar but as 2 days (the day before plus the correct day) for any Kopano delegates, for external MS users it shows as an All day the day before.
So just for a test I changed everything to Europe/Berlin (1 hour ahead) and the situation is exactly the same.
Sounds buggy to me?
-
I didn’t find a solution.
-
Yes, having the same issue with all day events. It shows like a 2 days event.
-
The problem still excist. The issue is there when using all day calendar items.
-
@ckruijntjens
Sorry, I’ve just tried exactly as described here to reproduce this on my site - without luck. My appointment is still in right place in attendee calendar and in my calendar.
My timezone definition for webapp is Europe/Amsterdam and on my Windows 10 Client using Firefox it is “UTC+1 Berlin, Amsterdam…”
Supported Kopano Packages in use (this maybe explains the difference):
WebApp: 5.3.0.0-1+172.1
Kopano Core: 8.7.25
Z-Push: 2.6.4+0-0Windows 10 Client is Pro 21H2 Version latest Patches 03/2022
Firefox used is x64 98.0So please describe what you’re using to give me possibility to test and reproduce this issue.
Andreas
-
@dw2412 Hi,
I am using the latest builds at this moment.
My issue was that the timezone was not configured properly ini php.ini
Now that this is correct it dont have the issue anymore.
-
webapp-6.0.0.66.a7d7f94-Debian_10-all.tar.gz
core-11.0.2.51.3b0b0e5-Debian_10-amd64.tar.gzAll on Deb 10, client PCs are openSUSE 15.3
We are using the Kopano kwebd as the front end web server for users with apache servicing webapp, I don’t know if that makes a difference but I don’t know why it would.
Dave
-
@nanathlor
Just to get you right, you’re using to create and to read the appointment always Kopano WebApp - in all timezones. I mean in Europe/London where you’ve created the appointment and on other Client PCs using MS Windows in Europe/Berlin Timezone, right? Appointment is created in Summer Time or in Winter Time or is it created on day where Summer/Winter Time or Winter/Summer Time chang occurs?Would be easier to reproduce if you could give exact details on how appointment as exactly created (mean which fields you exactly filled with what information).
Andreas
-
@dw2412 Sure, no problem.
Always creating the appointment Kopano Desktop or Webapp:
If I create an all day appointment for tomorrow and invite someone else.
In My calendar is shows correctly as an all day appointment for tomorrow.
In the invitees calendar it shows as a 2 day appointment for today and tomorrow
In my mobile (z-push) it shows as an all day appointment for today
I understand that in M365 it shows as an all day appointment for today too.If I create an all day appointment in Mobile (z-push) it works fine.
All PCs are Europe/London, same version OpenSUSE, same version Kopano Desktop.
It even works on my PC only i.e. if I send an appointment from my PC I can see the issue in other peoples calendars they have shared with me.
GMT/BST daylight savings has no bearing
I have tried changing to different timezones (e.g. Europe/Berlin) too same issueSenders calender:
Recipients calendar:
Note the date range at the bottom of the recipients calendar appointment:
php -i | grep Europe
Default timezone => Europe/London
date.timezone => Europe/London => Europe/LondonDave
-
@ekpack same error here
did you find any slolution? -
@klipp
No, till now, i haven’t found a solution. -
@ekpack
two of our developers tried to debug and fix the bug today but kopano is doing some crazy and wired stuff in webapp so we were not able to find the bug without further information from kopano.
i seems like kopano community version is going to die soon -
I do have the same problem using the latest nightly builds.
Does anyone already have a solution to this?
Regards
Richard