Put the guidance into practice: open the related free tool. Examples use stated inputs and are not measured performance claims.
| Event field | Purpose | Check |
|---|---|---|
| DTSTART | Event start | Correct UTC instant |
| DTEND | Event end | Later than the start |
| SUMMARY | Event title | Clear and recognizable |
| LOCATION | Event location | Useful to an attendee |
| UID | Event identifier | Does not itself send updates |
A calendar record is a snapshot
An iCalendar event can describe a title, start, end and location. The QR image stores that description so a supporting application can offer to add it to a calendar. It does not create a hosted event page or send invitations merely because the record contains event fields.
If the schedule changes later, the printed payload remains unchanged. A person who already imported it may continue to see the old time. For an event with a changing schedule, a stable event page can be a better destination, with current calendar downloads managed there.
State what the code does in the surrounding instruction. Saving an event is different from registering, buying a ticket or reserving a place. Do not let the convenience of calendar import imply that attendance has been confirmed.
UTC makes the instant explicit
Tidy QR labels its calendar date-time fields as UTC. The generated event uses UTC values rather than silently interpreting the input as the browser's local time. This removes one hidden assumption, but it requires the person entering the event to supply the correct UTC instant.
A date-time input without a time-zone offset can be misleading if its label is ignored. Before generating the code, convert the event's intended local time using a trusted calendar or time-zone tool appropriate to the event date. Seasonal clock changes can make a remembered offset wrong.
The receiving calendar may display that instant in the user's own time zone. A different visible hour after import can therefore be correct. Compare the underlying event and expected local display rather than assuming every screen should show the same hour.
A worked UTC event example
Choose an illustrative event starting at 14:00 UTC and ending at 15:00 UTC on the selected date. Enter those UTC values and a clear title and location. The duration is one hour by subtraction of the stated times; it is an example input, not a published event schedule.
Generate the code, inspect the VEVENT payload and import it into a test calendar. Check the displayed time zone, start, end and date. An event that crosses midnight in the attendee's zone may appear on a different local date from the UTC entry.
Delete the test event after checking if it is not needed. The purpose of the proof is to verify the imported record, not to distribute a real invitation or notify attendees. Calendar import and outbound invitation delivery are separate actions.
Preserve the format rather than hand-building lines
RFC 5545 defines iCalendar content lines, escaping and folding. Titles and locations can contain punctuation that needs correct handling. Tidy QR builds the record from fields so those characters are not mistaken for structural separators.
The event includes an identifier and timestamp, but their presence does not make the QR code a synchronization service. A receiving calendar may use identifiers when handling records, yet a static image has no mechanism to deliver a future replacement automatically.
Keep the content concise and useful. Long descriptions increase payload density and can make the code harder to print small. If attendees need extensive instructions, link to an event page and use the calendar record for the core scheduling information.
Device support is a separate question
A general camera can recognize a QR symbol without offering calendar import for every payload. The application may display the record as text or require another app to interpret it. This is why a successful local decode is necessary but not sufficient for the intended user experience.
Test on the devices or calendar applications that matter for the audience. Review the actual imported event rather than stopping at a prompt. A title can look correct while the end time or location is missing.
Provide the event date, time and location in readable text alongside the code. A person should be able to understand the essential schedule without scanning, and the printed details give them a way to compare the imported result.
Changes need a communication plan
If an event is rescheduled, replace digital and printed copies of the old code where practical. Update the public event page and communicate through the channels attendees already use. Do not assume that changing a source file reaches people who previously imported the record.
For a recurring program, a stable schedule page may avoid distributing fixed event details too far in advance. The page can present the current event and a fresh calendar download. That approach has a website-maintenance dependency, but it makes the update path explicit.
Keep the original payload with the approved artwork so a later discrepancy can be traced. It helps determine whether the wrong instant was entered, a receiving application interpreted it differently or the event itself changed after publication.
Check the physical and scheduling layers
Print the final code with its quiet zone and test it at the intended size. Then inspect the imported event. A camera recognizing the pattern does not establish that the calendar fields are right, and a correct event on a large screen does not prove the printed code is readable.
Review the instruction as well. If it says save the date, the code should lead to the appropriate calendar action or a clearly labeled event page. If registration is required, make that separate step explicit.
A useful calendar code removes transcription without hiding the schedule. Keep the time-zone assumption visible, verify the import and retain a readable version of the information people need to attend.
Check boundary dates deliberately
Events near midnight deserve a specific review because a UTC instant can fall on another local date. The printed invitation should state the event's intended local schedule clearly, while the imported record should represent the same instant. Compare both date and time after import.
The current form creates timed events, not an all-day or recurring-event editor. Do not simulate an all-day event by entering arbitrary midnight boundaries and assuming every calendar will label it correctly. Use an appropriate calendar workflow when the event needs features beyond the implemented fields.
For a test involving seasonal clock changes, verify the conversion for the actual event date. Reusing an offset remembered from another month can create a plausible-looking but incorrect result. Keep the conversion decision with the approved event details so another editor can review it.
Frequently asked questions
Does the code send invitations?
No. It contains a static event record. Invitation delivery and attendance registration are separate services.
Why does the imported time look different?
The calendar may display the UTC instant in its selected local time zone. Check both the zone and the intended instant.
Will rescheduling update old scans?
Not automatically. Replace the code and use an appropriate communication or event-management channel for changes.
Sources
Last checked: . Examples are illustrative inputs, not measured results.
- RFC 5545: iCalendar, RFC Editor. Checked 2026-10-29.
- Scan a QR code with your iPhone or iPad, Apple. Checked 2026-10-29.
- Scan QR codes with your Pixel phone, Google. Checked 2026-10-29.
- Implementation specifications, checked against source code, Tidy QR. Checked 2026-10-29.