The timezone setting in the appointment booking system is particularly relevant for internationally active service providers who serve customers in different countries or regions with different timezones. Without correct timezone handling, serious misunderstandings can occur: a customer in New York books an appointment for "3:00 PM", while the advisor in Berlin expects the appointment to take place at "9:00 PM" (German time). The timezone function solves these problems through automatic conversion and transparent display.
Why timezones matter
The Earth is divided into 24 timezones (from UTC-12 to UTC+14). If a service provider works in Germany (UTC+1/+2) but serves customers in the USA (UTC-5 to UTC-8), Australia (UTC+8 to UTC+11) or Asia (UTC+5 to UTC+9), availability must be converted correctly. A wrong timezone leads to missed appointments, frustration and bad reviews.
Use cases
1. Online coaching and consulting
A life coach in Berlin offers video consultations for customers worldwide. Their availability is Monday to Friday from 9:00 AM to 5:00 PM (Berlin time). A customer in Los Angeles (9-hour time difference) automatically sees this availability as 12:00 AM to 8:00 AM (California time) and can choose a suitable slot accordingly.
2. International remote teams
A company with locations in London, Dubai and Singapore uses an appointment booking system for internal meetings. Every employee sees availability in their local timezone, but the system coordinates everything centrally.
3. Virtual events and webinars
A webinar provider in New York schedules an event for 6:00 PM EST. Participants from Europe automatically see "midnight CET", participants from California "3:00 PM PST", without manual conversion.
4. Traveling service providers
A photographer works alternately in Berlin and New York. When in New York, they change their timezone in the system: their German customers still see correct times in CET, while their New York customers see EST times.
How it works
1. Operator timezone (server timezone)
The operator specifies which timezone they work in (e.g. "Europe/Berlin"). All availability is stored internally in this timezone.
2. Automatic detection of the customer's timezone
When a customer opens the booking page, the system automatically detects their timezone (via browser settings or IP geolocation). Availability is then displayed in their timezone.
3. Transparent display
The system clearly shows the customer which timezone the times are displayed in:
- "All times in Pacific Standard Time (PST)"
- "Times in your local timezone (GMT+1)"
- Optional: a timezone selection dropdown, in case automatic detection does not fit
4. Correct storage
Internally, all appointments are stored in UTC (Coordinated Universal Time), the global standard timezone without daylight saving time shifts. This keeps appointments unambiguous and independent of local timezone changes.
5. Email notifications
In confirmation and reminder emails, the appointment is shown both in the customer's timezone and (optionally) in the operator's timezone:
- "Your appointment: Monday, March 15, 2025, 10:00 AM PST (7:00 PM CET)"
Configuration
- Globally for the entire system: One central timezone for all calendars
- Per calendar: Different calendars can work in different timezones (e.g. Berlin location = CET, New York location = EST)
- Automatic daylight saving time adjustment: The system automatically takes daylight saving time (DST) into account, in Germany CEST instead of CET in summer
Challenges and solutions
1. Daylight saving time changes
In many countries, the clocks are changed twice a year. The system must take these changes into account automatically, otherwise errors occur. Modern booking systems use timezone databases (e.g. the IANA Time Zone Database) that contain all historical and future daylight saving time rules.
2. Ambiguous times
When the clocks go "back", one hour exists twice (e.g. 2:30 AM CEST and 2:30 AM CET). The system must store unambiguously which one is meant.
3. Countries without daylight saving time
Not all countries observe daylight saving time (e.g. Japan, China, Iceland). The system must be able to handle this.
4. Half-hour and quarter-hour timezones
Some countries have unusual timezones (e.g. India = UTC+5:30, Nepal = UTC+5:45). The system must process these correctly.
Best practices
- Transparency: Always show which timezone times are displayed in
- Allow manual selection: If automatic detection fails, the customer should be able to choose the timezone manually
- Show both timezones in emails: Both the customer's and the operator's timezone, to avoid misunderstandings
- Calendar synchronization: With CalDAV synchronization with Google Calendar, Outlook, etc., transfer timezones correctly
Combination with multilingual support
Timezone and language are often related:
- A customer in France wants the booking form in French and times in CET
- A customer in Quebec wants French and EST
The system should make both configurable independently of each other.
Technical implementation
- Frontend: JavaScript detects the browser's timezone via
Intl.DateTimeFormat().resolvedOptions().timeZone - Backend: All times are stored in UTC in the database
- Conversion: Every time something is displayed, it is converted from UTC to the target timezone
- Timezone database: The IANA Time Zone Database (e.g. "Europe/Berlin", "America/New_York") is used
Common mistakes and how to avoid them
- Storing only the offset (e.g. "+1"): Does not work with daylight saving time changes → Use the full timezone name instead ("Europe/Berlin")
- Ignoring the client timezone: Showing all times only in the operator's timezone → Customers have to convert manually, high error rate
- No transparency: Customers do not know which timezone times are displayed in → Misunderstandings guaranteed
Benefits of correct timezone handling
- No missed appointments: Customers show up at the right time
- Professional image: An international focus is taken seriously
- Fewer support requests: No confusion about "wrong" times
- Globally scalable: The system can be used worldwide
Example scenario
- Operator: Coach in Berlin (Europe/Berlin, UTC+1 winter time)
- Customer 1: In New York (America/New_York, UTC-5)
- Customer 2: In Tokyo (Asia/Tokyo, UTC+9)
- Availability: Monday, 10:00 AM to 6:00 PM Berlin time
What do the customers see?
- Customer 1 (New York): Monday, 4:00 AM to 12:00 PM EST
- Customer 2 (Tokyo): Monday, 6:00 PM to 2:00 AM JST (partly on Tuesday)
What happens when booking?
- Customer 1 books "10:00 AM EST"
- The system stores "15:00 UTC"
- The operator sees "4:00 PM CET"
- Customer 2 sees (if they open the appointment) "12:00 AM JST (Tuesday)"
Everyone sees the same appointment, just displayed in their respective timezone.