Booked meeting time incorrectly in Synology Calendar and Apple Calendar

[wachirapohn]

Issue Summary

Timezone mismatch when integrating Calcom with Synology Calendar (CalDav) and Apple Calendar. Meetings booked on Calcom with Asia/Bangkok (GMT+7) timezone are appearing in Synology Calendar and Apple Calendar with UTC (GMT+0) timezone, resulting in incorrect appointment times.

Steps to Reproduce

1. Integrated Calcom with Synology Calendar.
2. Booked a meeting on Calcom with a timezone set to Asia/Bangkok (GMT+7).
3. The meeting appointment was sent to Synology Calendar.
4. Observed that the appointment on Synology Calendar displayed the timezone as UTC (GMT+0) instead of Asia/Bangkok (GMT+7).
5. Repeated the process with Apple Calendar and encountered the same issue.
6. Changed the timezone in Calcom settings and attempted to book another meeting.
7. The issue persisted despite the changes.

Actual Results

• The timezone for meetings in Synology Calendar and Apple Calendar is set to UTC (GMT+0) instead of the selected timezone Asia/Bangkok (GMT+7), leading to an incorrect meeting time.

Expected Results

• The meetings booked through Calcom should reflect the correct timezone (Asia/Bangkok GMT+7) on both Synology and Apple Calendars, matching the time initially set when booking the appointment.

Technical details

• Calcom
  • OS: Ubuntu 22.04.3 LTS (Jammy Jellyfish)
  • Platform: Linux
  • Arch: x64
  • Docker: Yes
  • Calcom version: v.3.7.9-sh
• Browser
  • Chrome: Version 120.0.6099.227 (Official Build) (64-bit)
  • Edge: Version 121.0.2277.83 (Official build) (64-bit)
  • Firefox: Version 122.0
• Calendar
  • Synology Calendar: Version: 2.4.6-20944
  • Apple Calendar: Latest version

Evidence

• Booked on Calcom

• Synology Calendar (While clicking on the event, it shows the correct time, but when Edit Event, it shows the incorrect time as pictures)

• Apple Calendar (Booked the same as Synology Calendar)(It's show GMT+0 Time)

• docker-compose.yaml

#Use postgres/example user/password credentials
version: '3.8'

volumes:
database-data:

networks:
stack:
name: stack
external: false

services:
database:
container_name: database
image: postgres
restart: always
volumes:
- database-data:/var/lib/postgresql/data/
env_file: .env
networks:
- stack

calcom:
image: calcom/cal.com:main
restart: always
networks:
- stack
ports:
- 31090:3000
env_file: .env
environment:
- DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DATABASE_HOST}/${POSTGRES_DB}
depends_on:
- database

#Optional use of Prisma Studio. In production, comment out or remove the section below to prevent unwanted access to your database.
studio:
image: calcom.docker.scarf.sh/calcom/cal.com
restart: always
networks:
- stack
ports:
- 31091:5555
env_file: .env
environment:
- DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DATABASE_HOST}/${POSTGRES_DB}
depends_on:
- database
command:
- npx
- prisma
- studio
#END SECTION: Optional use of Prisma Studio.

• .env

#Set this value to 'agree' to accept our license:
#LICENSE: https://github.com/calendso/calendso/blob/main/LICENSE

#Summary of terms:
#- The codebase has to stay open source, whether it was modified or not
#- You can not repackage or sell the codebase
#- Acquire a commercial license to remove these terms by emailing: license@cal.com
NEXT_PUBLIC_LICENSE_CONSENT=
LICENSE=

#BASE_URL and NEXT_PUBLIC_APP_URL are both deprecated. Both are replaced with one variable, NEXT_PUBLIC_WEBAPP_URL
#BASE_URL=http://localhost:3000
#NEXT_PUBLIC_APP_URL=http://localhost:3000

NEXT_PUBLIC_WEBAPP_URL=http://localhost:31090

#Configure NEXTAUTH_URL manually if needed, otherwise it will resolve to {NEXT_PUBLIC_WEBAPP_URL}/api/auth
#NEXTAUTH_URL=http://localhost:3000/api/auth

#It is highly recommended that the NEXTAUTH_SECRET must be overridden and very unique
#Use openssl rand -base64 32 to generate a key
NEXTAUTH_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#Encryption key that will be used to encrypt CalDAV credentials, choose a random string, for example with dd if=/dev/urandom bs=1K count=1 | md5sum
CALENDSO_ENCRYPTION_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

#Deprecation note: JWT_SECRET is no longer used
#JWT_SECRET=secret

POSTGRES_USER=xxxxxxxxxxxxxxxxxxxxxxxxx
POSTGRES_PASSWORD=xxxxxxxxxxxxxxxxxxxxxxxxxx
POSTGRES_DB=calendso
DATABASE_HOST=database:5432
DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DATABASE_HOST}/${POSTGRES_DB}
GOOGLE_API_CREDENTIALS={}

#Set this to '1' if you don't want Cal to collect anonymous usage
CALCOM_TELEMETRY_DISABLED=

#Used for the Office 365 / Outlook.com Calendar integration
MS_GRAPH_CLIENT_ID=
MS_GRAPH_CLIENT_SECRET=

#Used for the Zoom integration
ZOOM_CLIENT_ID=
ZOOM_CLIENT_SECRET=

#E-mail settings
#Configures the global From: header whilst sending emails.
EMAIL_FROM=xxxx@xxxxx.com

#Configure SMTP settings (@see https://nodemailer.com/smtp/).
EMAIL_SERVER_HOST=xxxxxxxxxxxxxxxxxxxxxxxxx
EMAIL_SERVER_PORT=xxxxxxxxxxxxxxxxxxxx
EMAIL_SERVER_USER=xxxxxxx@xxxxxxxxx.com
EMAIL_SERVER_PASSWORD=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

NODE_ENV=production

Thank you!

[maige-app]

Thank you for reporting this issue with timezone mismatches in Synology Calendar and Apple Calendar integrations. We will look into this as it seems to be a regression. In the meantime, if you have any more information or steps that could help us reproduce the issue, please feel free to share.

_{From Maige. How's my driving?}

[wachirapohn]

Could you please provide an update on the current status? I've attempted to resolve the issue using various methods, yet it persists. I would appreciate any guidance or recommendations you might have to address this matter effectively. Thank you.

[wachirapohn]

Any advice for this issue?