What you are seeing
The code scans, but the calendar event it creates is wrong: the wrong date, the wrong time, a missing location, or a garbled title. The scan worked, so the fault sits in the event payload: the date format, the time zone, or a field the phone parses differently. Calendar payloads are fussy about date and time shapes, and a small format error can shift an event by hours or days. The fix is to decode the payload and to rebuild it with the calendar generator in the standard format.
Likely causes
1.
Date or time in the wrong format — A date written in a format the phone does not expect can be misread, shifting the event. Test: decode the payload and read the date and time fields.
2.
Time zone missing or wrong — An event without a time zone, or with the wrong one, can appear hours early or late on the visitor's phone. Test: compare the time zone in the payload with the intended one.
3.
Hand-typed payload with a format error — A hand-typed event payload can carry a wrong separator, a missing field, or a wrong field order. Test: compare the payload with the standard event format.
4.
Missing end time — An event without an end time can appear with a default length that does not match the real event. Test: check whether the payload carries an end time.
5.
Special characters in the title or location — A comma, semicolon, or line break in a title or location can break the field structure. Test: try a simple title with plain characters and compare.
Step-by-step fix
1. Decode the payload and write down the title, start, end, location, and time zone it carries.
2. Compare every value with the intended event details.
3. Rebuild the event with the calendar generator, using the verified details.
4. Scan the rebuilt code and read the created event carefully, including the time zone.
5. Fix any field that differs, and retest.
6. Retest the final code on two phones and confirm the event is correct.
Putting this into practice
In practice, the time zone is the field that bites. An event that looks right in your calendar can appear hours off on a visitor's phone if the time zone is missing or wrong. Always set the time zone explicitly, and always read the created event on a test phone before printing. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Hand-typing a calendar payload and shifting the event by hours because the time zone was missing.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that scans but the calendar event is wrong will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans but the calendar event is wrong.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The decoded date, time, and time zone match the intended event
- The event carries an explicit end time
- Scanning creates the correct event on two phones
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [calendar event QR code generator](/calendar-event-qr-code-generator)
- [QR payload inspector](/qr-payload-inspector)
- [QR offline verifier](/qr-offline-verifier)
- [QR scan log](/qr-scan-log)
- [QR safety checker](/qr-safety-checker)
- [blog](/blog)
