update event --all-day false on a recurring all-day event is silently ignored and corrupts the stored dates

[SpoonJimSquareSocks]

Environment: ekctl 1.5.0 (also observed in production on 1.3.0), macOS 26.x (Tahoe), iCloud/CalDAV calendar.

Summary

Converting a single recurring all-day event to a timed event via update event … --all-day false --start … --end … is silently ignored and corrupts the event's stored dates, instead of either performing the conversion or returning an error.

Repro

1. Have a recurring all-day annual event (a Birthdays-style yearly event) on an iCloud calendar.
2. Convert one occurrence to a timed event:

ekctl update event <EVENT_ID> \
  --start 2026-06-26T18:00:00-04:00 \
  --end   2026-06-26T20:00:00-04:00 \
  --all-day false

Expected

The event becomes a timed 18:00–20:00 event — or ekctl returns a clear error if all-day→timed conversion on a recurring series is unsupported.

Actual

• The event stays all-day; the supplied --start/--end times are ignored (it normalizes to 00:00–23:59 on the date).
• A subsequent read shows a timezone artifact: the all-day June-26 event reads back as 2026-06-25T20:00:00 → 2026-06-26T19:59:59 -04:00 — i.e. midnight-to-midnight stored in UTC and surfaced across the −04:00 offset.

The event is left corrupted; update reports success.

Where (v1.5.0 source)

Sources/ekctlCore/EventKitManager.swift, updateEvent(...):

if let startDate = startDate { event.startDate = startDate }   // L339
if let endDate   = endDate   { event.endDate   = endDate   }   // L340
…
if let allDay = allDay { event.isAllDay = allDay }             // L348
…
try eventStore.save(event, span: .thisEvent)                   // L375

On a recurring master, saving with span: .thisEvent while toggling isAllDay appears to make EventKit re-clamp the dates to all-day boundaries, dropping the supplied times. CLI parsing is not the cause — update event declares @Option var allDay: Bool?, so --all-day false is correctly conveyed as allDay = false.

Suggested fix

Detect an all-day↔timed transition on a recurring event and either handle it correctly or fail loudly with a clear message, rather than silently saving a corrupted event. A clear error is an acceptable outcome; the silent corruption is the real problem.

[SpoonJimSquareSocks]

Confirmed reproducible from scratch on ekctl 1.5.0 (macOS 26.x, iCloud) — self-contained, no pre-existing event needed:

# 1. scratch calendar + a recurring all-day event
CAL=$(ekctl calendar create --title ekctl-rid-test | jq -r .id)
ekctl add event --calendar "$CAL" --title "rid test" \
  --start 2027-03-01T00:00:00-05:00 --end 2027-03-02T00:00:00-05:00 \
  --all-day --recurrence-frequency weekly --recurrence-end-count 4
# -> base id <BASE>, allDay:true

# 2. convert one occurrence to timed
ekctl update event <BASE> \
  --start 2027-03-01T18:00:00-05:00 --end 2027-03-01T20:00:00-05:00 --all-day false

update returns "status":"success", but:

• the response shows allDay:false yet start/end are unchanged (00:00:00 → 23:59:59) — the 18:00–20:00 times are silently dropped;
• ekctl show event <BASE> immediately after reports allDay:true again (the conversion didn't persist on the master);
• ekctl list events over the range shows the first occurrence detached into a corrupted instance: allDay:false, startDate 2027-02-28T19:00:00-05:00 — i.e. the all-day date stored at midnight UTC and surfaced across the −05:00 offset (id suffix /RID=825552000).

Net: one update … --all-day false on a recurring all-day event corrupts the series instead of converting it (or erroring).

Tangential, in case it's useful: event(withIdentifier:) does resolve the resulting …/RID=825552000 detached-occurrence id for show/update/delete, so the detached id is at least addressable.

Cleanup: ekctl calendar delete "$CAL".