I still don't understand what is the purpose of that dummy entry.

Its trigger is bogus, and its action is none.

Yes, I agree it's weird. Let me first summarize draft-daboo-valarm-extensions, which gives insight into Apple's line of thinking, and then provide some interpretation:

• SUMMARY

In https://tools.ietf.org/html/draft-daboo-valarm-extensions-04#section-11, Cyrus Daboo (Apple) provides an explanation:

11. Default Alarms in CalDAV

    Users often want to have a default alarm applied to new events that
    they create or to new invitations that arrive on a CalDAV [RFC4791]
    server. Since this behavior is expected to occur no matter which
    client a user is using, or whether any client is even connected at
    the time, it is beneficial if the server itself is responsible for
    managing the creation of the default alarm.

ACTION:NONE as a placeholder for "User does not want a default alarm" is described in Section 11.3 (https://tools.ietf.org/html/draft-daboo-valarm-extensions-04#section-11.3).

The last paragraph before Section 10.1 (https://tools.ietf.org/html/draft-daboo-valarm-extensions-04#section-10.1) explains the use of the dummy 19760401T005545Z DATETIME for backward compatibility (although for a different use case).

• INTERPRETATION

Current servers do not provide support for the default alarm properties (and are unlikely to do ever, since the I-D has not been updated in over two years). Apple tries to approximate this client-side, with a similar behavior as explained in the rest of Section 11 in the above I-D.

Therefore, each Apple client checks to see whether any alarm is set at all; if none is set, and it has a default alarm, it adds its default alarms. This creates two usability problems:

1. With multiple devices and shared calendars, finding the culprit which added an alarm to an event can be very hard. (Only a few days ago I changed a repeating event in one of the calendars and now they all happily alarm again, even if they should not)

2. Disabling default alarms on all devices also has the disadvantage that for the 90%+ of events that I want to have alarms (and typically two), the UI on MacOSX iCal now requires what feels like 20 mouse movements, delays, and clicks to add these two alarms.

The dummy entry (expired alarm with no action) prevents the clients from doing this automatic addition. In fact, any entry would do, but this one is defined to do nothing and is the one that the other clients would insert themselves.

BTW: As part of the initial PROPFIND on /SOGo/dav/user/Calendar/ iCal (MacOSX) asks for the properties at the end of this note. This – interestingly – includes default-alarm-vevent-date and default-alarm-vevent-datetime.

Apple's CalendarServer also seems to implement this property (look for default-alarm in https://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/release/CalendarServer-5.2/twistedcaldav/caldavxml.py and DefaultAlarm in https://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/release/CalendarServer-5.2/twistedcaldav/resource.py), which does allow the clients to synchronize their default alarm settings (which would be helpful in itself to have a consistent view).

I did not find code where the server modifies calendar entries, so these four properties could be implemented as transparent properties for client-to-client exchange with minimal impact as well.

<?xml version="1.0" encoding="UTF-8"?>
<A:propfind xmlns:A="DAV:">
  <A:prop>
    <A:add-member/>
    <C:allowed-sharing-modes xmlns:C="http://calendarserver.org/ns/"/>
    <D:autoprovisioned xmlns:D="http://apple.com/ns/ical/"/>
    <E:bulk-requests xmlns:E="http://me.com/_namespace/"/>
    <D:calendar-color xmlns:D="http://apple.com/ns/ical/"/>
    <B:calendar-description xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:calendar-free-busy-set xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <D:calendar-order xmlns:D="http://apple.com/ns/ical/"/>
    <B:calendar-timezone xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <A:current-user-privilege-set/>
    <B:default-alarm-vevent-date xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:default-alarm-vevent-datetime xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <A:displayname/>
    <C:getctag xmlns:C="http://calendarserver.org/ns/"/>
    <D:language-code xmlns:D="http://apple.com/ns/ical/"/>
    <D:location-code xmlns:D="http://apple.com/ns/ical/"/>
    <A:owner/>
    <C:pre-publish-url xmlns:C="http://calendarserver.org/ns/"/>
    <C:publish-url xmlns:C="http://calendarserver.org/ns/"/>
    <C:push-transports xmlns:C="http://calendarserver.org/ns/"/>
    <C:pushkey xmlns:C="http://calendarserver.org/ns/"/>
    <A:quota-available-bytes/>
    <A:quota-used-bytes/>
    <D:refreshrate xmlns:D="http://apple.com/ns/ical/"/>
    <A:resource-id/>
    <A:resourcetype/>
    <B:schedule-calendar-transp xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:schedule-default-calendar-URL xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <C:source xmlns:C="http://calendarserver.org/ns/"/>
    <C:subscribed-strip-alarms xmlns:C="http://calendarserver.org/ns/"/>
    <C:subscribed-strip-attachments xmlns:C="http://calendarserver.org/ns/"/>
    <C:subscribed-strip-todos xmlns:C="http://calendarserver.org/ns/"/>
    <B:supported-calendar-component-set xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <B:supported-calendar-component-sets xmlns:B="urn:ietf:params:xml:ns:caldav"/>
    <A:supported-report-set/>
    <A:sync-token/>
  </A:prop>
</A:propfind>