fix(agenda): all day event offsets, locale display

[tnyeanderson]

Currently, allDay events are off by one day for negative timezones. Per the CalendarContract:

If allDay is set to 1 eventTimezone must be "UTC" and the time must
correspond to a midnight boundary.

For example, in GMT-2:00, an all day event on December 2nd (beginning at 00:00:00) will be wrongly displayed as starting on December 1st, since the locale will determine that the event's start time is actually 22:00:00 on Dec 1.

Source:

https://developer.android.com/reference/android/provider/CalendarContract.Events.html

This commit:

• Corrects the offset back to UTC 00:00:00 for allDay events

• Fixes the conditional for single-day all day events in showEvent()

• Fixes the display of formatDateShort() for some English locales by also removing any trailing commas or whitespace when the year is removed

[tnyeanderson]

@glemco it seems like you're the de facto owner of the agenda app, so mentioning you here :)

[glemco]

Thanks for taking care of this! I remember testing this across time-zones was quite convoluted and I didn't know about this Contract.
Added some minor comments but it looks good to me.

[glemco]

While this looks clever, requires the reader to check your comment to understand why you'd subtract what's basically a boolean value from a timestamp. I'd be a bit more verbose just for the sake of clarity, what do you think?

Suggested change

	// All day events end at the midnight boundary of the following day. Here, we
	// subtract one second for all day events so the days display correctly.
	var end = getDate((+ev.timestamp) + (+ev.durationInSeconds) - ev.allDay, ev.allDay);
	// All day events end at the midnight boundary of the following day. Here, we
	// subtract one second for all day events so the days display correctly.
	const allDayOffset = ev.allDay ? 1 : 0;
	var end = getDate((+ev.timestamp) + (+ev.durationInSeconds) - allDayOffset, ev.allDay);

[tnyeanderson]

Hilariously, that's exactly what I had wanted to do, but decided to be "clever" since it's an embedded device with minimal resources, etc (in the name of efficiency). Even told the wife how I already hated what I'd done :)

Every time I do something "clever", I regret it, so I'm glad we agree! lol

[tnyeanderson]

To avoid colliding with the "offset" concept in getDate(), I chose a slightly different name than you did above. Let me know if this is alright with you.

[glemco]

Good catch, that was actually not too readable and I got myself confused.. I wonder if we should change it to something like sameDay, that'd probably be more meaningful

[tnyeanderson]

I agree that this should be renamed, but sameDay would reverse the current boolean's values, and that variable is used in quite a few places that would have to be fixed.

I was already planning on doing a second pass with some cleanup like this to help make the code a little more clear, so I'll take care of the variable renaming then to avoid having too many changes in this PR, which might make it harder to understand.

[tnyeanderson]

Should be ready for a final review. Thanks!