Edit ICS text: check two UTC fields without importing

What does an ICS time check actually decide?

This manual text exercise compares the saved start and end fields of a local calendar file with an explicitly supplied event intention. A filename or meeting title does not prove that the time values mean what the owner intended. This exercise does not open a calendar account, send an invitation or import an event.

The complete fictional intention is 23 October 2026, 10:00 to 10:30 in Asia/Baku. Europe/London is the second explicitly named comparison zone. That intention is an input, not something inferred from an inconsistent file. If the owner has not specified the intended date, zone or occurrence, stop with a clarification rather than selecting a convenient instant.

The deliverable is an untouched original, a separately saved corrected ICS and a readback note. The author wrote and reopened this controlled fixture in an existing Python environment and checked the two zone conversions. That is a local synthetic runtime result, not an Anar or client case, a calendar-import trial or proof of compatibility with every application.

The meeting time-zone guide resolves an ambiguous repeated local hour before an invitation is prepared. Here the intention is already fixed; the new work is repairing contradictory serialized fields and reading the saved file. A conversion alone would not establish a new file-validation result, and a corrected file cannot supply missing human intent.

How do you preserve and identify the inconsistent source?

The original below is deliberately malformed training input. UID identifies the fictional event; it is not an attendee address. DTSTAMP is the fixture's creation timestamp, not the appointment start. DTSTART and DTEND carry the event boundaries. The surrounding BEGIN and END lines preserve the calendar and event containers.

On Windows, open Start, search for Notepad and create a new blank document. Copy the complete text. Choose File, Save as, select a new private practice folder, enter practice-original.ics, select All files and UTF-8, then save. If that name already exists, stop rather than overwriting it. Open the source only as text; importing this intentionally inconsistent fixture is not part of the exercise.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Practice//Local Time Check//EN
BEGIN:VEVENT
UID:ICS-PRACTICE-041@example.invalid
DTSTAMP:20261021T080000Z
DTSTART;TZID=Asia/Baku:20261023T100000Z
DTEND;TZID=Asia/Baku:20261023T103000Z
SUMMARY:Practice only ICS-041
END:VEVENT
END:VCALENDAR

Both event-time lines contain TZID=Asia/Baku and a terminal Z. RFC 5545 prohibits applying the TZID parameter to a UTC DATE-TIME. Z is a UTC marker, not a decorative suffix that can simply be attached to a local Baku clock reading. The file therefore cannot be treated as an unambiguous statement of the supplied intention.

Do not speculate about which component a particular calendar client would prefer. No client interpretation of the malformed input has been tested. The complete file-name check helps you distinguish practice-original.ics from an accidental .ics.txt file, but the correct extension is not a conformance certificate. This fixture has no recurrence, participant, reminder or external attachment.

Why does the corrected start become 06:00Z?

The supplied start is 10:00 on 23 October in Asia/Baku. The existing zone database gives that date an offset of plus four hours, so the corresponding UTC start is 06:00. The supplied 10:30 end becomes 06:30 UTC. Both fields must preserve the same intended half-hour interval.

Our one repair route expresses the event boundaries in UTC and removes TZID from those two lines. Merely deleting the parameter while keeping 10:00Z would change the intended instant. Conversely, removing Z while retaining a regional parameter would open a different local-time representation and its timezone-definition requirements. That is not the route taught here.

Create another blank Notepad document and copy the corrected file below. Use File, Save as and the separate name practice-corrected.ics in the practice folder, again choosing All files and UTF-8. Keep the original intact. If practice-corrected.ics already exists, stop and restart both file-creation steps in a new empty practice folder, keeping the specified names. The code does not discover alternative filenames.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Practice//Local Time Check//EN
BEGIN:VEVENT
UID:ICS-PRACTICE-041@example.invalid
DTSTAMP:20261021T080000Z
DTSTART:20261023T060000Z
DTEND:20261023T063000Z
SUMMARY:Practice only ICS-041
END:VEVENT
END:VCALENDAR

Check the literal fields: DTSTART:20261023T060000Z and DTEND:20261023T063000Z. The date precedes T, the clock includes seconds and the final Z identifies UTC. The report-day UTC audit decides which IDs belong within a reporting boundary; this exercise preserves a known event instant in a saved calendar representation instead. Do not reuse a report-day inclusion rule as an invitation repair rule.

What should the two explicit zones display?

The corrected file stores UTC, while the table shows two regional presentations of the same interval. The date is essential: the London result concerns 23 October, not an autumn clock-change occurrence on another day. Do not replace Europe/London with a universal fixed plus-one-hour assumption. A named zone is a date-dependent rule, not merely a city label.

The same instant appears as 10:00 in Baku and 07:00 in London under the existing environment's data for this date. The UTC end is thirty elapsed minutes after its start. These are controlled calculations, not screenshots from a recipient's calendar. Future timezone-rule changes and differing installed data remain relevant outside this fixture.

An unchanged 10:00Z field would not match the supplied Baku 10:00 intention. However, we do not assign a guaranteed display to the original malformed combination. An application might reject or interpret inconsistent data differently; none of those behaviors was measured here. Keep the syntax fault separate from the corrected result.

The version-reference check likewise preserves the original alongside a changed state. Saving a corrected ICS does not establish that a real organizer approved the appointment or that a recipient accepted it. Human intention is explicitly supplied only for this fictional exercise. No METHOD:REQUEST, attendee address or delivery operation is added to manufacture an invitation workflow.

How can an existing Python environment read the saved file?

This optional runtime route requires an already working Python 3.9 or newer environment, available zoneinfo data and permission to use the local terminal. There is no installation, package download or administrator action. If those prerequisites are absent, preserve NOTRUN for the runtime check and compare the text with the supplied table without importing it into a live calendar.

Open your existing terminal in the practice folder. In a new Notepad document, paste the code. Use File, Save as in the practice folder, name it check_ics.py and select All files and UTF-8; stop if that name exists. Verify the complete name is not check_ics.py.txt. Run python check_ics.py there using your established Python command. If the command, folder or named zone is unavailable, stop with the actual error. Do not treat a suggested installation as part of this short exercise.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo
from pathlib import Path
raw = Path("practice-corrected.ics").read_text(encoding="utf-8")
fields = {}
for line in raw.splitlines():
    if line.startswith(("DTSTART:", "DTEND:")):
        key, value = line.split(":", 1)
        fields[key] = datetime.strptime(value, "%Y%m%dT%H%M%SZ").replace(tzinfo=timezone.utc)
for zone in ("Asia/Baku", "Europe/London"):
    print(zone, fields["DTSTART"].astimezone(ZoneInfo(zone)).isoformat(),
          fields["DTEND"].astimezone(ZoneInfo(zone)).isoformat())
print("minutes", (fields["DTEND"] - fields["DTSTART"]).total_seconds() / 60)

The expected lines show Baku 10:00–10:30, London 07:00–07:30 and minutes 30.0. The code reads DTSTART and DTEND from practice-corrected.ics itself, then converts them using the standard library's zoneinfo support. Python's official documentation explains named timezone conversion; it does not make this short field reader a complete iCalendar validator.

The reader intentionally handles only these fixed UTC fields. It does not validate recurrence rules, folded content lines, arbitrary value types, VTIMEZONE components or every calendar client's requirements. No third-party iCalendar parser is installed in the available environment, and none was installed for this exercise. The general AI guide gives broader process context; a local bounded check should never be relabelled as approval of a complete production system.

What should remain in the saved readback note?

Open a separate blank Notepad document. Record the original and corrected filenames, the supplied intention, the two changed fields, the two zone results and the runtime command or NOTRUN status. Preserve expected and observed values separately. Do not copy the answer table into an observation column merely because the output looks plausible.

Press Ctrl+S, choose the practice folder and save ics-readback-V1.txt; use a new version name if it exists. Close the editors. In File Explorer, reopen the actual saved note with Open with, Notepad. Compare its intention, two fields, zone results and observed or NOTRUN status. Then open both ICS files through the same text-only route: preserve the original conflict and check the corrected UTC fields. Do not double-click an ICS into a calendar application.

Save three claim decisions with their reasons. Reject TZID and Z can be combined freely on the same UTC field, using the format rule. Reject removing TZID always preserves the original clock digits, using the supplied Baku intention and UTC conversion. Reject local readback proves delivery, using the fact that no account, import, participant or send action occurred.

A proposed fifteen-minute exercise budget allocates five minutes to source text, five to repair and zone comparison, and five to saved-file readback. It is not a measured timing promise; unknown software availability may prevent completion. Stop with the local files and honest unresolved checks. A valid-looking saved file is not proof of correct real-world scheduling, recipient rendering, acceptance or future timezone data. No real contact details belong in this practice folder.