[Bug]: Public appointments are shifted by one day when scheduled on non-default timezone

[hbarel]

Steps to reproduce

1. Go to an appointment scheduling page.
2. Change from the default timezone to another timezone.
3. (Note that the availability you see is not for the displayed date, but for the previous day. If the selected date is 2024-10-05, then you see availability of 2024-10-04.)
4. Select a time to proceed.
5. Notice that the selected appointment that appears is for that same time on the previous day, not the date you selected in the previous screen.

Expected behavior

The date of the appointment should be the date you selected on the previous screen.

Actual behaviour

The date of the appointment is one day before the date you selected on the previous screen.

Calendar app version

No response

CalDAV-clients used

No response

Browser

Chrome

Client operating system

Debian

Server operating system

No response

Web server

Apache

Database engine version

MariaDB

PHP engine version

PHP 8.2

Nextcloud version

No response

Updated from an older installed version or fresh install

Updated from an older version

List of activated apps

No response

Nextcloud configuration

No response

Web server error log

No response

Log file

No response

Browser log

No response

Additional info

No response

[SebastianKrupinski]

Hi @hbarel

Can you recreate this issue and post the event, you can export it from the Calendar app.

Sebastian

[hbarel]

Hi @SebastianKrupinski ,

The event is okay, the problem is with the date selection in the appointment setting page.

If you go to an appointment setting page of a NC user, and change the default time-zone to another timezone, any date you click to set an appointment will result in possible times displayed of the previous day, rather than of the day you selected. When you actually select a time, an appointment will be set for the previous day also. Even before the event is actually created, you can already see it in the summary box before clicking "Book the appointment"; it will show you a date that is one day before the one you clicked in the appointment setting.

[SebastianKrupinski]

Tested. Confirmed.

Selected first slot on selection page...

The appointment detail page shows incorrect date...

[hbarel]

Hi @SebastianKrupinski , please note that in version 5.0.5, it seems as the problem is not resolved. Moreover, is now also affects meetings in the current (default) time-zone as well.

[SebastianKrupinski]

Hi @hbarel,

I just re-tested this on the newest version and I am getting the correct results.

Can you tell me which time zones you are testing with? What is your default time zone and what time zone are you changing to?

[hbarel]

Hi @SebastianKrupinski , I am testing it now from Asia/Jerusalem and always get the day shifted by (-1). I think that it worked well when I tested it 2-3 days ago, when I was at Europe/Berlin. Not sure if this is related or if the app code may have changed in between.

[SebastianKrupinski]

Hi @hbarel

Can you tell me what the original appointment booking schedule timezone is? (this should be the same time zone as your calendar, but could be different) The bestway would be if you could pull the 'availability' field from the 'calendar_appt_configs' table. Also, what is the time zone that your browser is using, you can get that by visiting this site https://webbrowsertools.com/timezone/

Unfortunately, all these have an effect on the appointments booking screen, and would help me determine what the issue is.

[SebastianKrupinski]

@hbarel One more thing, can you also share a screen shot of the appointment slots. I will need this to compare it to the 'availability' data.

[hbarel]

Hi @hbarel

Can you tell me what the original appointment booking schedule timezone is? (this should be the same time zone as your calendar, but could be different) The bestway would be if you could pull the 'availability' field from the 'calendar_appt_configs' table. Also, what is the time zone that your browser is using, you can get that by visiting this site https://webbrowsertools.com/timezone/

Unfortunately, all these have an effect on the appointments booking screen, and would help me determine what the issue is.

Hi @SebastianKrupinski , and thank you for looking into this. The browser is using Asia/Jerusalem, and this is also the timezone of the calendar. A few days ago, the browser might have been at Europe/Berlin, and all seemed to work fine with that same calendar. (I cannot know for sure that the different behavior was indeed caused by the different browser time-zone, but I cannot think of any other reason, unless maybe the application app was updated again in between.)

[hbarel]

@hbarel One more thing, can you also share a screen shot of the appointment slots. I will need this to compare it to the 'availability' data.

It really did not matter. It happened on all days clicked. The date selected in practice was always the previous day compared to what the little calendar selector showed.

[SebastianKrupinski]

Okay, Can you do one more test for me? Can you create a new appointment schedule and see if you are still experiencing the same issue?

[hbarel]

Okay, Can you do one more test for me? Can you create a new appointment schedule and see if you are still experiencing the same issue?

Yes, I just created a new one, for another calendar (in same timezone), and the same occurs.

Before the app was upgraded the issue occurred only when switching away from the default timezone, and since the update it happens on the default timezone as well.

(I am sure that I saw the problem solved a few days ago, perhaps there was another app update, or it may be due to my being in another timezone at that time.)

[hbarel]

Upon further testing: when the current date is selected, it is selected properly. When any future day is selected -- the actual selected day is the previous day; regardless of the timezone.

When introducing this trivial change:

--- apps/calendar/lib/Controller/BookingController.php.orig
+++ apps/calendar/lib/Controller/BookingController.php
@@ -102,9 +102,10 @@
        // Convert start date to requesters selected timezone adjusted start and end of day in epoch
        // E.g "Mon, 18 Nov 2024 06:00:00 +0000" (America/Mexico_City)
        $startTimeInTz = (new DateTime($startDate->format('Y-m-d'), $tz))
+           ->modify('+1 day')
            ->getTimestamp();
        $endTimeInTz = (new DateTime($startDate->format('Y-m-d'), $tz))
-           ->modify('+1 day')
+           ->modify('+2 day')
            ->getTimestamp();

as one would expect: selecting today's date results in tomorrow being selected, but selecting any other day causes the right day to be selected.

[SebastianKrupinski]

@hbarel thanks for the testing.

I'm sure this might look like its working but logically this kind of does not make sense.

If the browser is sending "Nov 24th" you are then adding +1 day to make it "Nov 25th".

Are you able to post your 'availability' field data from the 'calendar_appt_configs' table? I have a hunch on what is causing this but need to see the data in that field.

Also, would you be able to capture the request data from your browser when you click on a specific date? And tell me what the date is.

It looks something like this:

[hbarel]

Hi @SebastianKrupinski ,

I'm not suggesting that it looks like it's working... You are right and it's not... The change I did only trades one drift for another drift. If before the change the immediately displayed date (today) causes the right selection to be made and other days causes a (-1) drift in the selection, then after the change the immediately displayed date causes a (+1) drift and the other dates come out okay.

When I click, for example, on 2024-11-30 on the calendar, the GET consists of: apps/calendar/appointment/7/slots?startTime=1732917600&timeZone=Asia%2FJerusalem (the epoch time of the beginning of that day on that timezone, as you noted in your comments)

I will have a look at the Availability field later, although I am confident that those are okay. When I click on a date, the availability that is displayed is exactly that of the date -1, which is going to be the date I will see once I select one of the slots. For example, when I click on 2024-12-03, I will see the availability dates of 2024-12-02, and when I click on any of the slots the confirmation box will indeed have 2024-12-02 stated on it.

[SebastianKrupinski]

@hbarel It is the issue I suspected.

So the fix I did correctly fixed time zones that are past your current timezone. e.g. Schedule is in American/Toronto (-5) and selecting American/Mexico -6, etc had the effect of rolling back the day -1.

But this exposed a logic flaw in the way we send the selected date from the UI to the back end. What is happening is that the UI is applying the timezone of your browser before sending the epoch date (timestamp) of 1732917600, this is "2024-11-30 T00.00.00" in your browsers time zone "Asia/Jerusalem". The issue occurs when we apply the time zone of the appointment schedule to the epoch time stamp.

This is proper for the Asia/Jerusalem time zone

1732917600 converts to Saturday November 30, 2024 00:00:00 (am) in time zone Asia/Jerusalem (IST)

This is what happens when we apply the appointment schedule time zone Europe/Berlin

1732917600 converts to Friday November 29, 2024 23:00:00 (pm) in time zone Europe/Berlin (CET)

So from our conversation, I'm guessing the appointment schedule was created when the calendar was set to a different time (Europe/Berlin). So when we apply the time zone, it incorrectly rolls the date back one day.

I will work on a fix for this, this week.

[hbarel]

Wow, this sounds complex... I hope the problem is not that sophisticated... By this logic, if I create a schedule in Asia/Jerusalem, and then open the appointment page from a browser in Asia/Jerusalem, and click on a date without changing away from "Asia/Jerusalem", then there should not be a problem. But there is... Before the fix, the problem occurred only when switching away from "Asia/Jerusalem", but after the fix in version 5.0.5 it happens also for the default timezone. The only exception when there is no problem is on the current date (today) when it is displayed, until you click on anything else. Sorry for not being familiar with the back-end, nor the front-end, to be more helpful...

[SebastianKrupinski]

Wow, this sounds complex... I hope the problem is not that sophisticated...

Yes dates, times and time zones are very complex.

By this logic, if I create a schedule in Asia/Jerusalem, and then open the appointment page from a browser in Asia/Jerusalem, and click on a date without changing away from "Asia/Jerusalem", then there should not be a problem. But there is...

Yes, setting the calendar to Asia/Jerusalem (if this is the browser time zone) and creating a new appointment schedule should make it work properly.

You can actually probably just change the system timezone (your computer) to Berlin this then should change your browsers time zone and this should work properly.

The only exception when there is no problem is on the current date (today) when it is displayed, until you click on anything else.

Yes this will work because when you first load the page it selects the current date and time (2024-11-24 T15:00:00), so when we apply a timezone with a 1 hour difference it changes to (2024-11-24 T14:00:00), so the time changes but the date stays the same.

[hbarel]

By this logic, if I create a schedule in Asia/Jerusalem, and then open the appointment page from a browser in Asia/Jerusalem, and click on a date without changing away from "Asia/Jerusalem", then there should not be a problem. But there is...

Yes, setting the calendar to Asia/Jerusalem (if this is the browser time zone) and creating a new appointment schedule should make it work properly.

But it doesn't... :-( The error occurs regardless of the time-zone, even when the browser is in the same timezone as the calendar.

[hbarel]

@SebastianKrupinski , what most puzzles me is this phenomenon that when the appointment selection page (the little calendar) appears, the current day marked would map to the real current day (and availability times will be displayed accordingly), but once that day is selected, i.e., you click that same day just for fun, that same calendar entry will map to the previous day (and the availability times will change accordingly.) It's just as if the initial display of the little calendar does not utilize the same getBookableSlots function, or more likely, that it calls getBookableSlots with a value which is not what is sent when you click that day's number yourself.

Does this happen to you as well?