Manual repair input guide
Fill the values that CalendarLint cannot infer safely, one repair scenario at a time.
Updated · Applies to: ICS ViewerOn this page
Use this guide when an Issues repair asks you to type a value. Each section matches a manual repair scenario in the workspace. Read the relevant section, then return to the repair form and enter the value in the shown format.
Before you type
Manual input means the calendar file does not contain enough evidence for CalendarLint to determine the correct value. Do not enter a value just because it passes the format check. Use the publisher's export history, the source calendar, or a trusted system record to establish the intended value.
CalendarLint keeps the original version unchanged. After entering a value, review the draft diff, apply it as a new version, and compare the new version with the original before importing it elsewhere.
Missing DTSTAMP: choose the actual UTC timestamp
DTSTAMP records when the calendar object was created or revised. It must be
a UTC DATE-TIME value in this form:
DTSTAMP:YYYYMMDDTHHMMSSZ
Example:
DTSTAMP:20261031T080000Z
Enter the real creation or revision instant from the publisher's source or saved export history. Convert the known instant to UTC before entering it. Do not use the time you happen to be repairing the file, the event start time, or the computer's current time unless that is also the actual creation or revision time.
Check that the date and clock fields are real values. The final Z is required
because this field is UTC; a local time without Z is not an equivalent value.
Duplicate UID: choose a stable new event identity
UID identifies the same calendar object across exports, updates, replies, and
cancellations. A duplicate UID can cause two master events to be treated as
one event or can make a later import overwrite the wrong object.
Enter a stable identifier that is not used by any other event in the calendar:
UID:design-review-follow-up@example.test
Prefer an identifier controlled by the calendar publisher, commonly a stable event identifier combined with a domain the publisher controls. Do not use a random value that will change on every export, an existing UID copied from another event, or a title that can change over time.
Before applying the repair, search the source for the replacement UID and confirm it appears nowhere else. If the two records are actually revisions of the same event, do not assign a new UID without first determining which record is the canonical object; changing identity can make a calendar client create a second event instead of updating the existing one.
Verify and apply the repair
After entering a manual value:
- Confirm the field has the required prefix and format.
- Read the draft preview and compare the exact changed line.
- Verify that event times, recurrence, attendees, and unrelated properties did not change.
- Apply the repair as a new version.
- Compare the new version with the original and test the exported copy in a non-production calendar first.
If the source does not provide enough evidence to choose a value confidently, leave the issue unchanged and ask the calendar publisher for the missing context.