@sdetweil
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:VEVENT
For 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:VEVENT
The 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 use dateEndFormat: "HH:mm"
.
But for an event with duration, spanning multiple days, the setting dateEndFormat: "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.