Your answer doesn’t seem to contradict my impression and the general idea of my new scripts.
No. In practice, the IDs should be unique; a clash is highly unlikely in your situation. And calendar ids are always unique.
But my main question remains: is there a hack to change the calendar of an event from one to another? i.e. literally “move” an event from one calendar to another, without going through the create-delete process ?
Otherwise try this (untested) -- pass the event id and the destination calendar id:
use scripting additions
use framework "Foundation"
use framework "EventKit"
on moveEventID:eventID toCalID:calID
-- create event store and get the OK to access Calendars
set theEKEventStore to current application's EKEventStore's alloc()'s init()
theEKEventStore's requestAccessToEntityType:0 completion:(missing value)
-- check if app has access; this will still occur the first time you OK authorization
set authorizationStatus to current application's EKEventStore's authorizationStatusForEntityType:0 -- work around enum bug
if authorizationStatus is not 3 then
display dialog "Access must be given in System Preferences" & linefeed & "-> Security & Privacy first." buttons {"OK"} default button 1
tell application "System Preferences"
activate
tell pane id "com.apple.preference.security" to reveal anchor "Privacy"
end tell
error number -128
end if
set theCalendar to theEKEventStore's calendarWithIdentifier:calID
set theEvent to (theEKEventStore's calendarItemsWithExternalIdentifier:eventID)'s firstObject()
theEvent's setCalendar:theCalendar
set {theResult, theError} to theEKEventStore's saveEvent:theEvent span:((current application's EKSpanThisEvent) + (current application's EKSpanFutureEvents as integer)) commit:true |error|:(reference)
if not theResult as boolean then error (theError's localizedDescription() as text)
end moveEventID:toCalID:
You can change it to use the calendar name easily enough.