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[bot]]

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?