Help with display of recurring event end date

Marg_C · 2013-09-06 06:00:31 UTC

I've got a Calendar events search page set up and it's functioning well. However, it's the display of the results I'm having some issues with... specifically with Recurring Calendar Events. I'm not sure if I've encountered a bug?
The following code is what I've used on the display format for Single Calendar Events, and it works perfectly:

%event_start_datetime_j% %event_start_datetime_F%%event_end_date^replace_keywords:neq_date:{event_start_date}:–{event_end_datetime_j} {event_end_datetime_F}^replace:–{event_end_datetime_j} {event_end_datetime_F}:%%event_short_start_time^notempty:,% %event_short_start_time%%event_short_end_time^notempty:–%%event_short_end_time%

It's basically saying as long as the end date is not the same as the start date it can be printed... and then where the end date has not been filled in, don't print the Matrix keywords (I initially tried chaining with empty or notempty and I couldn't get it to work for all possible date combinations). Dates are shown on the results page like the following, which is what we want:

7 September

9 September, 12pm-2pm

17 September-18 September

21 September-29 September, 9am-5pm

And this sort of output is successfully avoided:

9 September-9 September, 12pm-2pm

The trouble I'm having is with the Recurring Calendar Events display format when the code is changed to use instance keywords:

%instance_start_datetime_j% %instance_start_datetime_F%%instance_end_datetime^replace_keywords:neq_date:{instance_start_datetime}:–{instance_end_datetime_j} {instance_end_datetime_F}^replace:–{instance_end_datetime_j} {instance_end_datetime_F}:%%event_short_start_time^notempty:,% %event_short_start_time%%event_short_end_time^notempty:–%%event_short_end_time%

The modifiers don't appear to be working at all when the instance keywords are used. On a recurring event that spans 2 days, the end date doesn't show at all (e.g. 20 September, 3pm-4pm should be 20 September-21 September, 3pm-4pm). Sure I can revert back to using the event keywords for the end date, but there are too many opportunities for that to go horribly wrong, depending what sort of recurring events people end up putting in.

I've been staring at this a long time so I'm wondering if I'm missing something. Is there a way to do this, or have I encountered a bug with keyword modifiers and 'instance' keywords?

Thanks!

Bart · 2013-09-11 07:05:41 UTC

Haven't looked into this enough to be able to figure out what might be wrong, but in the meantime, maybe you can use the %event_duration% keyword somehow?

%event_duration:contains:day:print_end_day:dont_print%

Chiranjivi_Upreti · 2013-09-12 09:37:16 UTC

Hi Marg,

As far as I can see, the bold faced bit of the following keyword will not evalute as it contains nested keywords (wrapped in {}) which are outside the scope of "replace_keywords" modifier:

%instance_start_datetime_F%%instance_end_datetime^replace_keywords:neq_date:{instance_start_datetime}:–{instance_end_datetime_j} {instance_end_datetime_F}^replace:–{instance_end_datetime_j} {instance_end_datetime_F}:%

Also in the keyword %instance_end_datetime^replace_keywords:neq_date:{instance_start_datetime}%, the dates compared will be in YYYY-MM-DD HH:MM format, unlike when using %event_end_date^replace_keywords:neq_date:{event_start_date}%, in which the date compared will be like for example "21st Oct 2013" and will not have the time bit.

Therefore when you are comparing %instance_end_datetime% and %instance_start_datetime%, you are comparing both date and time, which will always evaulte to TRUE for "neq_date" modifier unless both end and start date time of the instance are exactly the same.

Chiran

Marg_C · 2013-09-13 02:33:17 UTC

Haven't looked into this enough to be able to figure out what might be wrong, but in the meantime, maybe you can use the %event_duration% keyword somehow?

%event_duration:contains:day:print_end_day:dont_print%

Good suggestion Bart, thanks. I'll give that a try!

Hi Marg,

As far as I can see, the bold faced bit of the following keyword will not evalute as it contains nested keywords (wrapped in {}) which are outside the scope of "replace_keywords" modifier:

%instance_start_datetime_F%%instance_end_datetime^replace_keywords:neq_date:{instance_start_datetime}:–{instance_end_datetime_j} {instance_end_datetime_F}^replace:–{instance_end_datetime_j} {instance_end_datetime_F}:%

Also in the keyword %instance_end_datetime^replace_keywords:neq_date:{instance_start_datetime}%, the dates compared will be in YYYY-MM-DD HH:MM format, unlike when using %event_end_date^replace_keywords:neq_date:{event_start_date}%, in which the date compared will be like for example "21st Oct 2013" and will not have the time bit.

Therefore when you are comparing %instance_end_datetime% and %instance_start_datetime%, you are comparing both date and time, which will always evaulte to TRUE for "neq_date" modifier unless both end and start date time of the instance are exactly the same.

Chiran

Thanks Chiran, I figured the problem might be that the keywords are outside the scope of replace_keywords... I guess to request this to be changed is more a feature request than a bug.

You're right about the datetime thing though, of course - they'll never be different. Ideally you would use %instance_start_date% and %instance_end_date%, but they don't exist.

I might request this feature, if Bart's suggestion doesn't work. I'll post an update when I've given it a try.

Thanks to both of you!

Marg_C · 2013-09-13 03:47:28 UTC

Ideally you would use %instance_start_date% and %instance_end_date%, but they don't exist.

Hmm, it looks like this might have been changed in 4.16 as this is no longer the case - we upgraded last week, and I've had some sick days, so I hadn't noticed!

Marg_C · 2013-09-13 04:22:04 UTC

Ok, the crux of the problem here is that the %instance_...% keywords aren't compatible with the replace keywords modifier. I'm going to have to put in a feature request.

On the up side, %instance_start_date% and %instance_end_date% have now been added... which will be very useful for this type of scenario if they can ever be made compatible with replace keywords...