1.14.4-beta4

What's fixed

Thanks to @spi43984 for testing the previous beta and providing precise calendar examples.

• Distinct events are no longer lost during deduplication. Occurrences are identified by UID, recurrence identity, start, and end, so separate events sharing a title and time remain separate.
• Broken all-day re-exports are restored. Events re-exported as same-timezone 00:00:00 through 23:59:59 are treated as all-day ranges with the correct inclusive calendar dates and exclusive end date.
• Recurring and multi-day events now use one occurrence-selection pipeline. This fixes several related cases:
  • overnight and multi-day recurrences losing their duration or later days;
  • all-day recurrences shifting dates in positive UTC offsets;
  • EXDATE or overrides incorrectly removing every occurrence on a day;
  • duplicate occurrence emission and sparse date queries returning intervening events;
  • masters or detached overrides disappearing when no RRULE is present;
  • parsed calendar data being mutated during filtering;
  • DATE and DATE-TIME RDATE occurrences being omitted;
  • spring-forward days being dropped from all-day spans.
• Missing metadata is deterministic. Events without CREATED or LAST-MODIFIED no longer receive a new timestamp on every call.

Behavior change

Timed recurring events are now assigned to the day on which they occur in the user's local timezone, consistently with one-off events and Daily Note queries. Previously, recurring events could use the organizer's calendar date instead.

Compatibility rule

The all-day recovery rule is intentionally narrow: start must be exactly 00:00:00, end exactly 23:59:59, and both values must declare the same timezone. Near-miss timed events and legitimate next-midnight 24-hour events remain timed.

Verification

• 119 Jest tests passed, with 1 pre-existing skip.
• 50 compiled-artifact contract tests passed.
• 47 occurrence tests passed in each of 9 host timezones from UTC-11 through UTC+14.
• The downloaded release assets passed the reported UID and Berlin all-day scenarios in Berlin, New York, and Kiritimati.

Known limitations

• RDATE values using the PERIOD form are not expanded.
• All-day compatibility inference is limited to the reported same-timezone 00:00:00 through 23:59:59 shape. Fractional-second values are invalid RFC 5545 DATE-TIME input; ambiguous next-midnight and 23:59:00 forms remain timed unless a concrete provider case establishes the intended semantics.

Install 1.14.4-beta4 through BRAT and please report any provider-specific recurrence or timezone cases you find.

Full implementation and test details: #254