You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create appointment schedule in local time zone (Europe/Berlin) UTC+1
Change browser time zone to (Asia/Jerusalem) UTC+2
Select a date e.g. 2024-11-26
Expected behavior
Should show slots for 2024-11-26
Actual behaviour
Shows slots for 2024-11-25
Calendar app version
Main
Test Results
Selected November 26, 2024 in Asia/Jerusalem which is epoch 1732579200000.
Epoch conversion for Asia/Jerusalem time zone
1732579200000 converts to November 26, 2024 00:00:00 (am) in time zone Asia/Jerusalem (IST)
Epoch conversion for Europe/Berlin
1732579200000 converts to November 25, 2024 23:00:00 (pm) in time zone Europe/Berlin (CET)
Epoch conversion for America/Toronto
1732579200000 converts to November 25, 2024 19:00:00 (pm) in time zone America/Toronto (EST)
Issue
UI sends the date in the browsers time zone as epoch without sending the actual time zone. The issue is that epoch is a static number of seconds from a specific start point and defines a different time for every time zone, so once the configuration time zone is applied to the date, this causes the date to roll back one day causing slots to be generated for the wrong date. Epoch time will also differ during Standard and Daylight Savings time.
Solution
Use string date instead of epoch time stamp
The text was updated successfully, but these errors were encountered:
Steps to reproduce
Expected behavior
Should show slots for 2024-11-26
Actual behaviour
Shows slots for 2024-11-25
Calendar app version
Main
Test Results
Selected November 26, 2024 in Asia/Jerusalem which is epoch 1732579200000.
Epoch conversion for Asia/Jerusalem time zone
Epoch conversion for Europe/Berlin
Epoch conversion for America/Toronto
Issue
UI sends the date in the browsers time zone as epoch without sending the actual time zone. The issue is that epoch is a static number of seconds from a specific start point and defines a different time for every time zone, so once the configuration time zone is applied to the date, this causes the date to roll back one day causing slots to be generated for the wrong date. Epoch time will also differ during Standard and Daylight Savings time.
Solution
Use string date instead of epoch time stamp
The text was updated successfully, but these errors were encountered: