Calendar travel time or separate buffers? Check both journeys
A 14:00–15:00 visit with thirty minutes of travel each way occupies 13:30–15:30 in your personal plan. The shared meeting, a travel reminder and the availability used by a booking page are separate things. Check each rather than assuming one field covers both journeys.
Illustrative 14:00–15:00 visit
| Record | Time | What to verify |
|---|---|---|
| Outbound personal block | 13:30–14:00 | Saved Busy state and calendar included by availability tool |
| Shared meeting | 14:00–15:00 | Actual agreed guest start/end |
| Return personal block | 15:00–15:30 | Return window visible to the intended availability check |
| Booking-page buffer | Configured in appointment schedule | Spacing on that booking page; do not infer a separate global Busy event |
What the documented controls actually say
Apple’s Mac event guide documents a Travel Time menu and warns that its value does not update automatically after a location change. That alone does not establish how a Google or Exchange availability service interprets the field, or prove a return trip has been reserved. Inspect the saved event and return window explicitly.
Google’s appointment-schedule guide describes Buffer time as adding time between appointments. This is a booking-schedule control, not evidence that the same time becomes a separate Busy event for every internal scheduling tool.
A worked three-block plan
For the illustrative 14:00–15:00 visit, place personal outbound travel at 13:30–14:00 and return travel at 15:00–15:30. Meeting 60 minutes + outbound 30 + return 30 = 120 minutes total. These durations are assumptions for the plan, not navigation estimates.
Keep the invitation at the actual agreed 14:00–15:00 time. Separate personal buffers avoid telling guests that the meeting itself starts at 13:30. If time or venue changes, review both travel blocks and any native Travel Time value.
Busy indicates availability; it is not an enforcement guarantee
RFC 5545 describes VEVENT and its TRANSP setting: opaque events can be considered in busy-time searches; transparent events do not block them. The standard does not guarantee that every provider reads every calendar, imports every field, or rejects conflicting invitations.
Save buffers in a calendar that your intended scheduling or booking flow actually checks. For Google appointment schedules, the availability-checking calendar choices also matter. Test a neutral block from the booking page or with a consenting colleague rather than declaring all clients protected.
Check details and visibility separately
Use a neutral travel-block title if route details are unnecessary. Inspect both item visibility and calendar sharing; an ICS CLASS value alone is not a universal access-control guarantee.
Keep this availability check separate from route/weather planning. The existing journey-planning guide addresses estimates and conditions; this guide focuses on which record a booking flow sees.
What it looks like
Cloud Calendars overview, using our product images. Provider settings and protocol examples described in this guide are separate from the screens shown here.
What to do
- Keep the shared meeting at the agreed time.
- Plan outbound and return intervals explicitly.
- Check saved calendar, availability and sharing.
- Test the actual booking flow after an edit.
Questions
- Does a travel-time menu prove the return trip is blocked everywhere?
- No. Inspect the return period and the exact calendar/availability service. Add and verify a separate personal block when needed.
- Does Busy stop someone sending me a conflicting invitation?
- It can inform availability checks; it is not a universal invitation-rejection rule.