ALL-DAY CALENDAR DATE — FIELD COMPARISON AND IMPORT CHECKLIST
Original fictional examples; no calendar-account import has been performed.

DATE-VALUED ONE-DAY FIELDS (property fragments, not a complete import file)
DTSTART;VALUE=DATE:20261115
DTEND;VALUE=DATE:20261116
Covers November 15 only. No TZID applies to DATE.

DATE-VALUED THREE-DAY FIELDS
DTSTART;VALUE=DATE:20261115
DTEND;VALUE=DATE:20261118
Covers November 15, 16 and 17. End is non-inclusive.

DIFFERENT REPRESENTATIONS
DTSTART:20261115T000000Z — UTC DATE-TIME, one instant.
DTSTART:20261115T000000 — floating DATE-TIME, not DATE.
DTSTART;TZID=America/Los_Angeles:20261115T000000 — named-zone DATE-TIME fragment; a complete standards-based file requires the referenced VTIMEZONE definition.
Do not combine TZID with DATE or UTC Z values. Do not append a numeric UTC offset to an iCalendar DATE-TIME value.

INDEPENDENTLY CALCULATED UTC MIDNIGHT EXAMPLES
Zone rules used: # version 2026f
2026-11-15 00:00 UTC -> UTC 2026-11-15 00:00 UTC+00:00; DATE label stays 2026-11-15
2026-11-15 00:00 UTC -> America/Los_Angeles 2026-11-14 16:00 UTC−08:00; DATE label stays 2026-11-15
2026-11-15 00:00 UTC -> America/New_York 2026-11-14 19:00 UTC−05:00; DATE label stays 2026-11-15
2026-11-15 00:00 UTC -> Asia/Tokyo 2026-11-15 09:00 UTC+09:00; DATE label stays 2026-11-15
2026-09-15 00:00 UTC -> UTC 2026-09-15 00:00 UTC+00:00; DATE label stays 2026-09-15
2026-09-15 00:00 UTC -> America/Los_Angeles 2026-09-14 17:00 UTC−07:00; DATE label stays 2026-09-15
2026-09-15 00:00 UTC -> America/New_York 2026-09-14 20:00 UTC−04:00; DATE label stays 2026-09-15
2026-09-15 00:00 UTC -> Asia/Tokyo 2026-09-15 09:00 UTC+09:00; DATE label stays 2026-09-15

LOCAL MIDNIGHT DAY LENGTHS (elapsed time measured between UTC instants)
2026-03-08 in America/Los_Angeles: 23 elapsed hours; one calendar-day interval.
2026-11-01 in America/Los_Angeles: 25 elapsed hours; one calendar-day interval.

ONE-EVENT REVIEW RECORD
1. Expected date: The date from the source, including its year and jurisdiction.
2. Source and owner: App, publisher, calendar and whether you can change this entry.
3. Source display: All-day status, visible date and any start/end time before export.
4. Exported DTSTART: Exact property line in the relevant VEVENT, if available.
5. Value type: DATE or DATE-TIME, including T, Z, VALUE and any TZID.
6. Exported DTEND: Type and exclusive end; compare it with DTSTART.
7. Destination display: Account, calendar, all-day status, dates, clock time and zone.
8. First point of difference: Source display, exported fields, imported record or viewer display.
9. Next action and evidence: Keep a copy, request a corrected export or make a supported narrow change.

BEFORE APPLYING A CHANGE
Keep the original export and a supported destination backup.
Compare one all-day sample, a timed sample and any relevant recurring exception.
Use a separately identifiable test destination if the application supports it; avoid repeated trials in a mixed personal calendar.
Ask the publisher or app support where DATE semantics first changed.
Inspect retained and unrelated events after the supported correction.
Keep private calendar URLs and appointment details in your own record.

Sources: RFC 5545 sections 3.2.19, 3.3.4, 3.3.5, 3.3.6, 3.6.1, 3.8.2.2 and 3.8.2.4; Google Calendar Help, Fix problems importing.
IANA Time Zone Database: https://www.iana.org/time-zones — version 2026f verified during this calculation.