# Calendar QR code saves the wrong time

> A calendar QR shows the wrong time when DTSTART is written as floating local time with no Z suffix and no TZID, so every phone interprets it in its own zone. Encode timed events in UTC with a Z suffix (phones convert correctly), or use an all-day event, which has no timezone at all.

Source: https://useqr.app/docs/troubleshooting/calendar-qr-code-wrong-timezone · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## 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](/calendar-qr-code) 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](/scan) 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](/qr-codes-on/invitations) 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](/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.

## Try it

- https://useqr.app/calendar
- https://useqr.app/scan
- https://useqr.app/validate