Default calendar: new date format parameter for a single timed event spanning multiple days

[evroom]

Feature Request.

I see a possible 'need' for a new date format parameter.
For a single, timed event, spanning multiple days.
E.g. spanningSingleEventDateFormat.

$ grep version /home/admin/MagicMirror/package.json
	"version": "2.30.0-develop",

[TestCal: TIMESPAN_HOLIDAY
November 25, 2024, 12:00 – November 27, 2024, 17:00]

BEGIN:VEVENT
DTSTART:20241125T110000Z
DTEND:20241127T160000Z
DTSTAMP:20241026T091719Z
UID:[email protected]
CREATED:20241026T090035Z
LAST-MODIFIED:20241026T090035Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:TestCal: TIMESPAN_HOLIDAY
TRANSP:OPAQUE
END:VEVENT

For a single, timed event, spanning one night, like an overnight flight, it is not really necessary, but not really bad either.

[TestCal: OVERNIGHT_FLIGHT
December 2, 2024, 20:00 – December 3, 2024, 04:00]

BEGIN:VEVENT
DTSTART:20241202T190000Z
DTEND:20241203T030000Z
DTSTAMP:20241026T091719Z
UID:[email protected]
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, timed event I am (personally) not really interested in the full end date format (dateEndFormat).
That is why I normally use dateEndFormat: "HH:mm".
But for a single, timed event, 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.

[sdetweil]

so , I saw. spanningSingleEventDateFormat
but maybe multiDayEventEndDateFormat .. just end as start was the same (ok) both above?

[evroom]

The name was just an example, multiDayEventEndDateFormat sounds good.
Do not understand this however:
“just end as start was the same (ok) both above”

[sdetweil]

in your examples above the formatting of the start part of the event was the same in each example , so you want a new variable to control JUST THE END formatting in this case

[evroom]

Ah, yes, hence your proposal for the variable name multiDayEventEndDateFormat.
With emphasis on the EndDateFormat.
In my first line I had to phrase it like this in order to make it clear at first glimpse:
a possible 'need' for a new end date format parameter.

[sdetweil]

so what should be its default value?

and its only when the start and end day are different? right

[evroom]

When I look at the existing default date formats, I would propose: multiDayEventEndDateFormat: "Do.MMM, HH:mm".
I myself will probably use dateEndFormat: "HH:mm" and multiDayEventEndDateFormat: "ddd MMM D - HH:mm", but that is because I am European and not used to write Oct 29th, for instance.

and its only when the start and end day are different? right

Right, I did write:
For a single, timed event, spanning one night, like an overnight flight, it is not really necessary, but not really bad either.
Displaying, for example Oct 29th, 22:00-04:00 would be okay and understandable, but then where do you draw the line?
I looked at various outcomes and will drop this wish.

[sdetweil]

I looked at various outcomes and will drop this wish.

what does that mean? "will drop this wish"

[evroom]

I am afraid, that the more I write, the more confusing it gets :-)

The 'wish' to keep overnight events using the dateEndFormat: "HH:mm", like a flight from Oct 29th, 22:00 to Oct 30th, 02:00.
So it will display: Oct 29th, 22:00 - 02:00, iso Oct 29th, 22:00 - Oct 30th, 02:00.
This example, for me, would make sense and is understandable.
But then I looked at examples like:
Oct 29th, 12:00 - Oct 30th, 11:00 --> Oct 29th, 12:00 - 11:00 (can get confusing)
Oct 29th, 12:00 - Oct 30th, 14:00 --> Oct 29th, 12:00 - 14:00 (not correct)

So, please forget the above and introduce multiDayEventEndDateFormat: "Do.MMM, HH:mm" for an event with start and end time, where the end date differs from the start date.

Single day event with start and end time:

Multi day events with start and and time:

[sdetweil]

thus why we don't display end in general
if you are IN the event time span, then you KNOW it

really only NEED to know when the next start is

[evroom]

Not quite sure I understand.

In general as in ALL events with start and end time?
Or are we still speaking of events with start and end time, where the end date differs from the start date?
Or are we only speaking of the 'overnight' events I mentioned?

Could you give a(n) example(s), please?

[sdetweil]

i was just saying in general

you REALLY only need to know the upcoming event start time.

once that time arrives , you are IN the event, and don't need to know the start time anymore.

and it will end when it ends, as scheduled or not. regardless what the calendar on the wall says

the problems you are describing trying to decide which formatting to use, is why we don't display end of events by default. hard to get it right for everything

[evroom]

Okay, I think I get it, but need to digest it a bit.
Default setting for showEnd is true, for one, hence, dateEndFormat comes to play.
Let me try a bit and I will get back to you on this.

[evroom]

Question in between:

'showEnd: true,
is effective when
timeFormat: "relative",
??

I do not see the end time when using 'relative', unless that is wanted.
And briefly looked at the Issues, but cannot determine if this is in one of them.

[sdetweil]

showEnd is only used in absolute

[evroom]

I think timeFormat: "dateheaders" could be the solution for me:

Although there seems to be a counter issue with sliceMultiDayEvents:

For fullday spanning event is works fine:

And the empty lines are consuming too much space on a crammed display.
Would be nice to have them removed.

sliceMultiDayEvents set to false is not really usable.
Looks like there is nothing planned on Oct 31st, Nov 2nd and Nov 3rd.
But that looks to be independent from the timeFormat setting, perhaps I missed something here.

[evroom]

Sam,

I am thinking to close this feature request.

I would be forced to use timeFormat: "absolute" anyway.
I think I like timeFormat: "relative" more and there is an alternative with timeFormat: "dateheaders".

Better to spend time on other, real Issues.
Unless you say you are already busy with it and see possibilities.

I could open an Issue for sliceMultiDayEventsand one for the dateheaders spacing.

[sdetweil]

i had not done the coding. YOU can change spacing w css

[sdetweil]

@evroom
so, for grins, want to try it out? see if it still might be worth it

git pull
then git checkout fixcaldates3

the code does this
dateFormat: absolute, assumes same day start/stop

						if (event.startDate !== event.endDate) {
							if(moment(event.startDate,"x").format("YYYYMMDD") === moment(event.endDate,"x").format("YYYYMMDD")){
								timeWrapper.innerHTML += "-";
								timeWrapper.innerHTML += CalendarUtils.capFirst(moment(event.endDate, "x").format(this.config.dateEndFormat));
							}
							else{
								timeWrapper.innerHTML += "-";
								timeWrapper.innerHTML += CalendarUtils.capFirst(moment(event.endDate, "x").format(this.config.multiDayEventEndDateFormat));
							}
						}

I have not submitted this change

[evroom]

End time seems to work with these settings, but begin and end date&time does not match dateFormat and multiDayEventEndDateFormat.

timeFormat: "absolute",
dateFormat: "MMM Do HH:mm",
dateEndFormat: "HH:mm",  // Default
multiDayEventEndDateFormat: "MMM Do HH:mm",
fullDayEventDateFormat: "MMM Do",  // Default
showEnd: true,  // Default
showEndsOnlyWithDuration: true,

In JSON this would be an issue (no space between name and value):
multiDayEventEndDateFormat:"Do.MMM, HH:mm",
But "correcting" it does not change the output above, so seems to be okay.

Additional question, for educutional purposes:

Where do I see calendar.js log entries like this?
Log.info(Starting module: ${this.name});
Do not see them in the pm2 log.
I do see them from calendarfetcherutils.js
Is it because of this not being present?
const Log = require("../../../js/logger");

[sdetweil]

all the log entries for the module_name.js are in the browser developers window
ctrl-shift-i
select the console tab .. by 'convention' you can filter on message content, so each message would need to include the module name, but put a unique part of the module name in the filter field..

if you would like that log joined with the console log you can use
MMM-Logging (and my enhancement of that for all the Log.xx types)
or https://github.com/MMRIZE/MMM-LogExt which does similar

formatting

the code says
if the DATE is the same for start and end use the dateFormat string
otherwise use the multiDaysDateEndFormat

I did NOT change HOW the two parts are cojoined

-

with no extra leading or trailing space (you could ADD a leading or trailing space in the format string)
start-end

[evroom]

Hello Sam,

Just want to apologise for not pursuing this issue and give an update.
I found myself a bit of lost in testing all scenarios related to it and trying to understand the results I see.
And I am currently trying to help out with MMM-Hoymiles-Wifi.
But I will get back to it.

[sdetweil]

no problem

[sdetweil]

I am submitting my calendar updates without this currently. I think it needs more testing

[evroom]

Yes, I agree.
I still cannot find time to pursue it.
Thx for your efforts so far.