How do I fix timezone issues in appointment booking?

Timezone bugs in appointment booking usually happen because the system stores, compares, or displays dates in different timezones without being explicit about it.

The safe approach

1) Store everything in UTC

• Save appointment timestamps in UTC in the database.
• Do not store local times as plain strings unless you also store the timezone.

Example:

• User books: 2026-10-15 2:00 PM America/New_York
• Store:
  • starts_at_utc = 2026-10-15T18:00:00Z
  • timezone = America/New_York

2) Keep the original timezone

For bookings, you often need the appointment’s intended local timezone:

• Provider’s timezone
• Clinic timezone
• Event location timezone

This matters for:

• recurring appointments
• DST changes
• displaying the correct local time later

3) Convert only at the edges

• Input: convert user-selected local time to UTC
• Database: keep UTC
• Output/UI: convert UTC to the viewer’s timezone or the appointment’s timezone

4) Never use the server’s local timezone implicitly

Common bug:

• new Date("2026-10-15 14:00") gets interpreted differently depending on environment
• server in UTC, browser in local time, and DB in another timezone

Use explicit timezone-aware parsing.

Common bugs and fixes

Bug: Off-by-one-hour during DST

Fix:

• Use IANA timezone names like America/New_York, not offsets like UTC-5
• Offsets change with daylight saving time; IANA zones handle this properly

Bug: Appointment shifts when displayed

Fix:

• Store absolute time in UTC
• Convert to the correct display timezone before rendering

Bug: Users see different slots than what gets booked

Fix:

• Generate available slots in the provider’s timezone
• Convert to user display timezone only for presentation
• Compare overlaps in UTC

Bug: Midnight date changes

Fix:

• Be careful with date-only fields
• A “date” plus “time” in local timezone may become the previous/next day in UTC
• Always pair date/time with timezone before conversion

Recommended data model

Example fields:

• appointment_id
• starts_at_utc
• ends_at_utc
• timezone
• created_at_utc

Optional:

• local_start_date
• local_start_time
• provider_timezone

Best practices

• Use IANA timezones: Europe/London, Asia/Kolkata, etc.
• Use a timezone-aware library:
  • JavaScript: Luxon, date-fns-tz, Temporal (where available)
  • Python: zoneinfo, pytz (legacy)
  • Java: java.time
  • .NET: DateTimeOffset, TimeZoneInfo
• Test around DST boundaries
• Log both UTC and local timezone during debugging
• Make booking confirmations show both:
  • local appointment time
  • timezone abbreviation, e.g. 2:00 PM EDT

Example workflow

1. User selects March 10, 2026 9:00 AM in America/Los_Angeles
2. App converts to UTC
3. Store 2026-03-10T16:00:00Z
4. When displaying:
   • To a Los Angeles user: 9:00 AM PDT
   • To a New York user: 12:00 PM EDT

If you want, I can also give you:

• a JavaScript example
• a Python example
• or a database schema + API design for timezone-safe booking systems.