For an international appointment, confirm the date, local time and named timezone for both the consultant and client. A familiar six-hour difference can become five hours around daylight-saving changes. Before treating a paid booking as ready to attend, compare the selected slot with the confirmation in each person's actual timezone.
This workflow is for consultants selling one-to-one appointments across borders. It addresses “What time are we both attending?” rather than buffer time, calendar capacity or how much to charge for a booking deposit.
Which timezone belongs to the booking?
The PayRequest Booking Calendar documentation describes a configured booking timezone, with Europe/Amsterdam as the default, and date/time selection during checkout. Check the timezone actually saved for your product. A default is not confirmation that it matches your business or the appointment location.
Inspect the real dashboard, customer selection and confirmation before relying on a local-time display. Do not assume that browser detection, an imported calendar or automatic conversion behaves identically across products. Calendly's timezone documentation illustrates why account, invitee and event-location settings matter, but those are Calendly behaviors, not a promise about PayRequest.
A booking-timezone example across the autumn change
Assume the consultant offers a session at 15:00 Europe/Amsterdam. The client is in America/New_York. These are original date-specific calculations using Python's zoneinfo database, not screenshots of PayRequest or a test of its calendar conversion.
| Appointment date in 2026 | Amsterdam appointment | New York equivalent | Difference |
|---|---|---|---|
| 19 October | 15:00, UTC+02:00 | 09:00, UTC−04:00 | 6 hours |
| 26 October | 15:00, UTC+01:00 | 10:00, UTC−04:00 | 5 hours |
| 2 November | 15:00, UTC+01:00 | 09:00, UTC−05:00 | 6 hours |
The dates cross two regions' autumn transitions. Reusing “09:00 New York” for 26 October would make the client arrive an hour early. Calculate the specific appointment date; do not save a permanent offset as a substitute for a named timezone. If timezone rules change, recompute future sessions from an updated timezone database.
Build a five-field confirmation card
Use this original preflight card before sending the final joining instructions:
| Field | Example for 26 October | Check |
|---|---|---|
| Business slot | 26 October 2026, 15:00 Europe/Amsterdam | Matches saved booking |
| Client equivalent | 26 October 2026, 10:00 America/New_York | Converted for this date |
| Session length | 60 minutes, illustrative | Same duration in both records |
| Joining context | Online session; agreed meeting address | Client knows where to attend |
| Payment state | Actual confirmed payment reference | Verified separately from time |
The card is your communication worksheet, not a list of built-in PayRequest fields. Include the date and year, not just “Monday at three.” For clients elsewhere, use their actual named zone and check whether conversion moves the appointment to the previous or following calendar day.
Check selection, confirmation and calendar view
Start with the configured product timezone and the saved appointment. Next, inspect the customer-facing selection and confirmation using a representative client environment. Compare both with the same date-specific calculation. If you offer an external calendar invitation, verify it too; an invitation is a separate artifact, not proof that every screen shows the right time.
A practical pass condition is agreement on one instant and one duration, even when the two local clocks differ. If a display is ambiguous, add explicit joining instructions with both times and named zones. Fix the discrepancy before the session rather than expecting the customer to infer what an unlabeled 15:00 means.
What changes for travel or in-person appointments?
For an in-person session, make the venue's local time explicit. A traveling client may have a phone still set to their home timezone. For online sessions, ask which zone they will be in on the appointment date, not where they usually live.
When rescheduling, calculate the new date from scratch. Confirm the replacement date, local times and duration; do not merely copy the old offset. Review any payment, cancellation or service terms separately. A timezone correction does not itself establish a refund, a new charge or changed attendance rights.
Keep booking time and payment status separate
A visible slot is not payment evidence. Likewise, a successful payment does not tell the client which timezone the joining instruction uses. Check the saved booking and actual payment state independently, and give the customer a clear route to ask about either.
Use the consultant booking-buffer example for preparation and spacing between sessions, and the online booking workflow for the broader purchase flow. Then review one international appointment with PayRequest Bookings and send a date-specific two-zone confirmation.
Editorial note: AI assisted with this article and cover. Documentation was reviewed on 7 October 2026. The timezone table is a reproducible calculation, not a live booking test or a claim of automatic calendar synchronization.
