Calendar QR code saves the wrong time

Three ways to write a time, one of them a trap

A calendar QR code carries an iCalendar (RFC 5545) VEVENT, and its DTSTART line can express the start time three ways:

Form	Example	Meaning
UTC	DTSTART:20260901T050000Z	Absolute instant; every phone converts to its own zone
Zoned	DTSTART;TZID=Asia/Kolkata:20260901T103000	Local time in a named zone; strict parsers want a matching VTIMEZONE block
Floating	DTSTART:20260901T103000	"10:30", in whatever zone the reading device is in

The floating form is the trap. It looks identical to the zoned form minus the label, so generators emit it constantly, and it means something different on every phone that scans it.

The classic failure

An organiser in Mumbai encodes a 10:30 meeting. The generator writes floating time:

DTSTART:20260901T103000        broken ("10:30 local", wherever scanned
DTSTART:20260901T050000Z       fixed) 10:30 IST, 07:00 CEST, 06:00 BST

Everyone in Mumbai sees 10:30 and nothing seems wrong. The attendee scanning from Berlin also sees 10:30 (their 10:30), and dials in four and a half hours late. Floating time fails only across zones, which is why it survives testing: the person who makes the code is almost never in a different timezone from themselves.

The off-by-offset failure

The opposite bug: a generator that appends Z to whatever you typed without converting. Type 10:30 meaning IST, get DTSTART:20260901T103000Z, which is 16:00 IST. The event is shifted by exactly your UTC offset, which is the fingerprint to look for: an event consistently 5 h 30 min off in India, 1 h off in the UK in summer.

The correct pipeline converts the wall-clock time you entered into UTC before appending Z. UseQR's calendar generator does exactly this: timed events are normalised to UTC basic format with the Z suffix, so the code carries one absolute instant and every phone renders it in its own zone. The zoned TZID form is deliberately avoided in QR payloads: it requires a VTIMEZONE definition to be fully portable, which bloats the payload for no benefit over UTC.

All-day events have no timezone at all

An all-day event uses a date, not a date-time:

DTSTART;VALUE=DATE:20260901

No zone, no offset, no conversion: 1 September is 1 September everywhere. For deadlines, festivals, opening days and anything without a meaningful clock time, encoding all-day sidesteps every failure on this page. (One quirk to know: DTEND for all-day events is exclusive, so a one-day event on the 1st ends VALUE=DATE:20260902.)

Verify before printing

Decode the finished code with our scanner and read the DTSTART line against the table above. Then do the only test that fully settles it: scan it on a phone set to a different timezone (change the zone in settings, or ask a remote colleague) and check the saved event's local time. Event and invitation printing runs in the thousands. This check costs one minute. For events with attendees across zones, put the city and zone in the event title or description text as well, so humans can catch what parsers miss. More on event-day usage in QR codes for events.

FAQ

Why does my calendar QR code show a different time on other phones?

The event time is encoded as floating local time (no Z suffix, no TZID), so each phone reads it in its own timezone. Re-encode the start time in UTC with a Z suffix and every phone will convert it correctly.

Why is my event exactly a few hours off for everyone?

The generator stamped Z onto the local time you typed without converting to UTC, shifting the event by your UTC offset. Regenerate with a tool that converts wall-clock time to UTC before writing DTSTART.

Should I use UTC or TZID in a calendar QR code?

UTC. It needs no VTIMEZONE definition, keeps the payload small, and renders correctly in every calendar app. TZID is designed for recurring events that must track a zone's DST rules, rarely what a printed QR encodes.

Do all-day events have timezone problems?

No. All-day events use VALUE=DATE with a bare date and no time component, so nothing is converted anywhere. Note that DTEND is exclusive: a single-day event on 1 September ends with the date 2 September.