A visible calendar reminder does not have to make the host unavailable
A calendar can contain information that is useful to see without representing occupied time. If an export treats every event as blocking, an informational reminder can remove availability even when its date and time are correct. Adjusting the time-zone conversion will not solve that classification error.
This guide uses an explicitly fictional receiving model for a host's calendar. It distinguishes a preparation reminder, an appointment and a closure. The result illustrates a supported export decision; it does not claim that every calendar application imports or displays events in the same way.
Establish what each event means to the owner
The host has three entries on 17 November 2026, expressed in Europe/Rome:
| Entry | Local interval | Owner's meaning |
|---|---|---|
| R-18 preparation reminder | 09:00–09:15 | A visible reminder to check the visit information; it does not reserve the host |
| V-18 customer appointment | 10:00–11:00 | The host is occupied |
| C-18 closure | 14:00–15:00 | The host is unavailable for appointments |
The owner confirms these meanings before any export change. If preparation actually required protected working time, the correct decision could be to keep it blocking. The developer should not decide that every event called a reminder is free time.
In the example, the source records already have correct dates, times and event identities. The exported entries all omit an explicit transparency distinction. The receiving model applies the iCalendar default and treats all three as consuming time.
Inspect the property that controls free/busy meaning
RFC 5545 defines the TRANSP property for an event. OPAQUE is the default and indicates that the event consumes time for free/busy searches; TRANSPARENT indicates that it does not. That property concerns availability searches, not whether an entry is useful to display.
The investigation compares the owner's classification with the exported property and the receiving model's occupied intervals. R-18 appears in the model's busy set even though the owner has explicitly classified it as informational. V-18 and C-18 are correctly blocking.
There is no evidence here of a missing event, a duplicate identifier or a shifted instant. The repair should address the classification rather than change unrelated calendar fields.
Make the narrow export change
The imagined exporter supports an explicit availability classification for each event. R-18 is therefore exported with TRANSP:TRANSPARENT. V-18 and C-18 remain TRANSP:OPAQUE. The source identity, title and timing of each event remain unchanged.
The receiving model has two separate operations. Its calendar display lists all three events. Its free/busy calculation includes only the opaque intervals. That is a deliberately stated model of the relevant semantics, not a report of testing a named commercial calendar client.
Separating those operations matters. Deleting the reminder would remove information the owner wants. Marking every event transparent would preserve visibility but incorrectly advertise the appointment and closure as free time.
Check both the display and the availability result
The completed fictional verification records:
| Check | Result after correction |
|---|---|
| Display list | R-18, V-18 and C-18 are all retained |
| R-18 interval in free/busy | Not included as occupied |
| V-18 interval in free/busy | Still occupied |
| C-18 interval in free/busy | Still unavailable |
| Event identity and timing | Unchanged for all three entries |
The appointment at 10:00 Europe/Rome on the stated November date is 09:00 UTC. A receiving display that uses UTC can show 09:00 without changing the appointment. The transparency correction must leave that instant intact. This provides a time-preservation control while keeping the central investigation on availability classification.
For a real deployment, inspect the receiving provider and the clients people actually use. Record how they interpret the event, how updates reach them and whether any separate availability rules override the imported property. The standard explains the data semantics; it does not prove the behaviour of an untested account or application.
Keep booking authority outside the reminder
Removing R-18 from the busy set does not create a confirmed booking. The business may still need to check the host, group size, activity or language arrangement before accepting a visit. A free/busy result is one input to that decision.
Similarly, the exported closure expresses the owner's unavailability in this model. It does not establish that every connected booking service has received the update or that an already agreed appointment has been cancelled. Those are separate operational questions.
The staff handover should identify who may change the classification and what evidence is required. An editor should not make an appointment transparent merely to make a conflict disappear from a view.
Preserve the rule when the calendar changes
Document the three categories using examples the owner recognises. Include a visible nonblocking reminder, an occupied appointment and a genuine closure in later regression checks. If a provider or export format changes, repeat both display and availability checks rather than looking only for the presence of the titles.
The completed decision is specific: retain the informational reminder, stop treating it as occupied time and preserve the appointment and closure. The user's desired calendar information survives while the availability calculation becomes consistent with the owner's rule.
Read RFC 5545, Time Transparency for the primary definition. The booking enquiry service places calendar evidence within the wider request and confirmation process. The project table helps record who decides the rule and what result the review should demonstrate.