Read the statement by Michael Teeuw here.
Cant use showEnd icloud cal
- 
 @evroom that looks better , is it better? 
 only w duration only applies to date-time eventsbut same day shouldnt have add end show (but i compared full internal date value, which includes a utc time value which would be different) its ‘more’ consistent with end showing, but illogical to me to have start and end on the same day 
- 
 so try this , new line 437. only show end if the end date is different than the start date if (this.config.showEnd && moment(event.startDate,"x").format("YYYYMMDD") !== moment(event.endDate,"x").format("YYYYMMDD")) {
- 
 In short, I think it is looking better now. 
 To make full profit from ‘showEnd: true’ one should use a ‘dateEndFormat’ that makes sense, not like mine.
 The only thing that I notice, is that ‘showEndsOnlyWithDuration’ is not doing anything.
 In my examples I only see a change when I toggle ‘showEnd’. urgency: 0, timeFormat: "absolute", dateFormat: "dddd MMM D - HH:mm", dateEndFormat: "HH:mm", fullDayEventDateFormat: "dddd MMM D", showEnd: true, showEndsOnlyWithDuration: true, getRelative: 0, showEnd: true, showEndsOnlyWithDuration: false, showEnd: false, showEndsOnlyWithDuration: true, showEnd: false, showEndsOnlyWithDuration: false, 
- 
 you don’t have a full day event across multiple days NOT repeating 
 examplevacation mon-friday allday 1 NON-repeating eventrepeating are handled differently 
 show start, but not repeating end
 with sliceMultiDayEvents:true, // for REPEATING only (1 day event 5 times)see each day of repeating 1/5 2/5 3/5 ... 5/5 then next day 2/5 etc@evroom said in Cant use showEnd icloud cal: To make full profit from ‘showEnd: true’ one should use a ‘dateEndFormat’ that makes sense, not like mine. sorry, don’t understand this, I thought prior note said TIME display on fullday events was wrong… endFormat is for events with time (IMHO) The only thing that I notice, is that ‘showEndsOnlyWithDuration’ is not doing anything. ok, the code here is // Add end time if showEnd if (this.config.showEnd) { if (this.config.showEndsOnlyWithDuration && event.startDate === event.endDate) { // no duration here, don't display end } else { timeWrapper.innerHTML += "-"; timeWrapper.innerHTML += CalendarUtils.capFirst(moment(event.endDate, "x").format(this.config.dateEndFormat)); } }BUT, 
 immediately AFTER this is the test for fullday events, which changes the timeWrapperSo, this would ONLY apply 
 not-fullday
 not repeating
 event start on Monday:20:00:end on Tuesday:6:00 sleep over at Bobslike this  I see the bug… testing 2 things to together 
- 
 @evroom 
 change lines 415 —if (this.config.timeFormat === "absolute") { // Use dateFormat timeWrapper.innerHTML = CalendarUtils.capFirst(moment(event.startDate, "x").format(this.config.dateFormat)); // Add end time if showEnd if (this.config.showEnd) { if (event.startDate !== event.endDate) { // duration here, display end if requested if(this.config.showEndsOnlyWithDuration){ timeWrapper.innerHTML += "-"; timeWrapper.innerHTML += CalendarUtils.capFirst(moment(event.endDate, "x").format(this.config.dateEndFormat)); } } } // For full day events we use the fullDayEventDateFormat if (event.fullDayEvent) {
- 
 Sorry, do not want to cause confusion. 
 One should probably not do a quick test right after a full working day:-)
 The number of test cases seems endless.Do I remove the earlier changes ((lines 437 and 439) before changing line 415 ? 
- 
 @evroom said in Cant use showEnd icloud cal: The number of test cases seems endless. indeed… calendar is a tricky beast Do I remove the earlier changes ((lines 437 and 439) before changing line 415 ? 
 no… the end of this change is just before the prior , match up that last lineworking on getting this into the update now, creating testcases! 
- 
 I have posted an updated fixcaldates2 this also resolves the showEndsOnlyWithDuration 
 and adds support for showEnd:true with full day events (non-repeating)
 like vacation mon-fri, all dayjust git pullto update… 
 this is my fork, not the official pull request at this timeif you are just getting this for the 1st time. do git clone https://github.com/sdetweil/MagicMirror.git newmm cd newmm git checkout fixcaldates2 npm run install-mm
- 
 Sam, The option showEndsOnlyWithDurationis not described yet on https://docs.magicmirror.builders/modules/calendar.html.The interaction / dependancy with showEndalso needs to be documented.I do not know if documentation issues also can / should be done on https://github.com/MagicMirrorOrg/MagicMirror. 
- 
 Sam, Whilst testing your last changes, I sort of see a need for a new date format parameter. 
 For an event with duration, spanning multiple days.
 E.g.spanningDayEventDateFormat.[TestCal: TIMESPAN_HOLIDAY] BEGIN:VEVENT DTSTART:20241125T110000Z DTEND:20241127T160000Z DTSTAMP:20241026T091719Z UID:1lk06o70p9bp21ln3pdfda4ng0@google.com CREATED:20241026T090035Z LAST-MODIFIED:20241026T090035Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:TestCal: TIMESPAN_HOLIDAY TRANSP:OPAQUE END:VEVENTFor events with duration. spanning one night, like an overnight flight, it is not really necessary, but not really bad either. [TestCal: OVERNIGHT_FLIGH] BEGIN:VEVENT DTSTART:20241202T190000Z DTEND:20241203T030000Z DTSTAMP:20241026T091719Z UID:0s4flhmaf7p6q5atemshns4upp@google.com CREATED:20241026T090148Z LAST-MODIFIED:20241026T090215Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:TestCal: OVERNIGHT_FLIGHT TRANSP:OPAQUE END:VEVENTThe reasoning behind it is following: 
 For a ‘normal’, single, event I am not really interested in the full end date format (dateEndFormat).
 That is why I normally usedateEndFormat: "HH:mm".
 But for an event with duration, spanning multiple days, the settingdateEndFormat: "ddd MMM D - HH:mm"makes more sense.dateFormat: “ddd MMM D - HH:mm” 
 dateEndFormat: “HH:mm”
 fullDayEventDateFormat: “ddd MMM D”
 [good for normal events, ‘bad’ for spanning events]:
  dateFormat: “ddd MMM D - HH:mm” 
 dateEndFormat: “ddd MMM D - HH:mm”
 fullDayEventDateFormat: “ddd MMM D”
 [‘bad’ for normal events, good for spanning events]:
  I hope I could explain it well enough. 
 And that it makes sense. :-)Best regards, E.J. 

