iCalendar floating time, UTC and TZID: which time does the file mean?
A bare 09:00 in an ICS timestamp does not always mean a meeting fixed to one instant. Identify whether the file uses floating time, UTC or a named time zone before deciding that another calendar moved the appointment.
Illustrative result for two fixed-offset readers
| Property form | Reader at UTC+02:00 | Reader at UTC+09:00 |
|---|---|---|
| 20261102T090000, no TZID | 09:00 local | 09:00 local |
| 20261102T090000Z | 11:00 local | 18:00 local |
| TZID=… with local value | Depends on referenced zone | Same instant, converted for this reader |
Recognize the three representations
RFC 5545 section 3.3.5 defines three DATE-TIME forms. A value without Z and without a TZID parameter is floating. A trailing Z means UTC. A local value with a TZID parameter refers to a time-zone definition. A VTIMEZONE component elsewhere in the file does not make a bare floating value zone-specific.
For example, DTSTART:20261102T090000 is floating. DTSTART:20261102T090000Z identifies 09:00 UTC. DTSTART;TZID=Europe/Paris:20261102T090000 uses a named zone; a complete interoperable calendar object must provide the necessary time-zone information. These are property illustrations, not three equivalent full import files.
Decide whether the clock hour or the instant should stay fixed
Consider two fictional people using fixed offsets UTC+02:00 and UTC+09:00. A floating 09:00 is intended to remain 09:00 in each person’s applicable local zone, so they would act at different actual instants. A 09:00Z meeting appears at 11:00 and 18:00 respectively. The table uses fixed offsets for arithmetic, not a claim about any city’s seasonal rules.
A local stretching reminder might reasonably follow the clock hour wherever the person is. A video meeting normally needs one shared instant. Ask the organizer which intention applies. Merely adding Z to a floating timestamp changes its meaning; it is not cosmetic cleanup.
Do not paste an ISO offset into an iCalendar DATE-TIME
The RFC does not permit a numeric UTC offset as part of this DATE-TIME value. A value such as 20261102T090000+0200 is not the iCalendar DATE-TIME form, even though similar offset notation is familiar elsewhere. Use a valid UTC value or a time-zone reference generated by the supported calendar system.
For named-zone recurring events, inspect occurrences around clock changes as well as the first date. A fixed offset used for this example is not a substitute for a named zone’s changing rules. This guide does not supply a complete VTIMEZONE generator.
Trace an apparent shift without rescheduling everyone
Compare the organizer’s confirmation, the original timestamp form and the receiving display zone. If the original represents one instant, a changed local display hour can be correct. Moving the event to restore the old visible hour can then change the actual meeting.
Cloud Calendars is a calendar application, not the authority that redefines RFC timestamps. This guide does not claim that its editor exposes raw TZID or floating-time controls. Make a necessary representation correction at the owning provider using supported controls, preserve the original and verify the result.
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
- Inspect Z and the TZID parameter before comparing visible hours.
- Write down whether the appointment means one shared instant or a local clock routine.
- Check the display zone separately from the stored event.
- Use the owning provider to correct a genuine mismatch; do not manually append offsets.
Questions
- Does VTIMEZONE make every timestamp in a file local to that zone?
- No. A DATE-TIME without Z or TZID is floating regardless of other VTIMEZONE components.
- Can two recipients see the same floating time but attend at different moments?
- Yes. Floating time can follow each recipient’s local clock. That is why it is usually unsuitable for a shared meeting instant.