API Booking at the Wrong Time? Check Time Zones

Find why an appointment moves by an hour or lands on the wrong day. Check the time sent, its time zone and how each connected app displays it.

A customer chooses 10am in Dublin, but another calendar shows 9am. That may be a display setting, or the integration may have saved the wrong time. Those are different faults. Before adding an hour to every booking, follow one made-up appointment through the source app, the API request and the destination. Check both the stored time and the time people see.

Things to check first

Write down the intended local date, time and named zone, such as Europe/Dublin. Include the actual date: the difference from UTC can change during the year. Avoid unclear dates such as 03/04.
Inspect the start and end values sent through the API. Does the value include an offset or a separate time-zone field? Cliniko expects dates and times in UTC. Google Calendar has its own rules for event offsets and named zones.
Check the viewer's calendar zone, the business zone and the workflow server zone. If the stored instant is right but one screen is different, fix the display setting rather than changing every appointment.

Google Calendar documentation example with an event time and Toronto time-zone setting — Google’s older interface example shows an event with its own time zone. The current screen may look different. Check the stored API time as well as the zone used to display it.
Screenshot: Google Calendar documentation. Example screen; yours may look different.

What to ask the freelancer to do

Trace a booking time through both apps
Correct the confirmed conversion or display fault
Test clock changes and date boundaries
Document time-zone rules for repeat visits

Questions to ask before hiring

Where does the local time become UTC or an offset time?
Will repeat visits stay at the same local hour after the clocks change?
Can you show a test near midnight and a clock-change date?

Red flags

Adds one hour to every booking
Drops the time-zone information before saving
Tests only today's date on one device

Agree what the job includes

Agree where the local booking time first becomes a fixed instant. Keep the named business zone when it is needed for future repeat visits. A fixed '+01:00' offset is not a year-round rule for Dublin.
Check start time, end time and duration together. Test a late-night booking that falls on a different date in UTC. Keep all-day events separate from timed visits; turning a date-only value into midnight can shift the date on another screen.
Test dates on both sides of a clock change. Some local times happen twice or do not happen at all when clocks move. Agree whether the booking app rejects an unclear time, asks the user or follows a documented vendor rule. Do not guess silently.

What to send the freelancer

Send two made-up examples: the chosen local time and the time shown in each app. Include the date and zone for each screen.
List the clinic, staff and customer zones that matter. State whether repeat appointments must stay at the same local hour.
Share redacted API values and test calendar access. Keep real names, appointment notes and invitation recipients out of the example.

How to check the work is done

The same test visit represents the intended instant in both apps, with the right local display and visit length.
Tests cover winter, summer, a clock-change date, a date boundary and a repeat visit. An unclear or missing local time follows the agreed rule.
The handover says where conversion happens and how future developers should handle date-only values and repeat bookings.

What may cost extra

Moving historical appointments in bulk needs separate approval and a list of affected records.
Changing a calendar display zone is not the same as moving every event. Extra countries and recurring-series repairs need their own tests.

Sources checked 23 October 2026

Use this guide to agree the work and check the result.

Common questions

Why is an appointment exactly one hour wrong?

A daylight-saving rule or a second conversion may be involved. First compare the stored API value with each app's display. The one-hour gap alone does not tell you which setting is wrong.

Should every appointment be stored in UTC?

Follow the vendor's rules. UTC is useful for a fixed instant, but a future repeat visit may also need a named time zone to stay at the same local hour. Cliniko and Google Calendar document different request formats.

More help: Source 1 · Source 2

Take the next step

Find help on Fiverr

Ready to hand it over? This freelancer offers help with the job covered in this guide. Look at their work and send them your brief to get a quote.

Sohail R.

@sohail91 · Fiverr

Calendar and workflow time-zone repair

This listing includes Calendar, Google Apps Script and n8n/API integrations. Ask whether it covers your time-zone fault and software. A simple automation package may not cover repeat-booking repairs.

The listing showed 248 reviews when checked. Reviews cover a range of jobs; they do not prove experience with your clinic software.

Before you hire: Ask for winter, summer, clock-change and near-midnight tests. Confirm that old appointments will not be moved in bulk.

View service on Fiverr ↗

Listing checked 2026-10-23. We have not hired this freelancer or tested their work.

Your project

Build my freelancer brief

Answer a few questions to make a clear job description you can send to a freelancer.

Build my brief →

Other guides that may help

Browse APIs, integrations & data services →