I won't comment on your problem, because I don't know how to reproduce it. I suspect you might have a conflict between the date format stored by your file and the date format used by your OS. This could likely be solved by cloning the file and importing your data into the clone. Or maybe you could just set the file to always use the file's stored format.

However, a more robust solution would prevent the problem from occurring under any circumstances: instead of a text field containing a returned-separated list of dates, use a proper date field with 3 repetitions. Hopefully the matchfield on the other side of the relationship is also a date field - otherwise you'll need an entirely different approach.

Heed comment tip on the use of anything but text in the "multi-line key" relationships. Note his use of Repeating field for the 'list of dates' (DATE type field with repetitions). You'll need to experiment with this as a way to have multiple dates (OR matches).

This may simplify the process of creating the 3 dates, but it will not solve the real problem here. When you convert the 3 dates to a return-separated list, the dates must be converted to text - and that's where the real problem is. At this point it doesn't matter how those dates were created.

We need to know what's on the other side of the relationship, and in which direction the relationship is meant to work (if it's a date, it will work in one direction only).

If all the calculation(s) can be indexed, the relationship will work bidirectional whatever its type.

Or i missed something important.

There is a difference in behavior when the matchfield is a date field on one side and a text field on the other. In one direction, the text will be converted to a date, and the relationship will function as expected. In the opposite direction, the date will be converted to text, and if the two texts do not match exactly (as described in the OP) the expected match will not happen.

Correct. The only thing that needs to be based on this behavior is avoiding it. But it is not always "easy enough to ensure the all date are well/identically formed" because the 'Always use current system settings' option is not implemented well enough.

Firstly I would like to say thanks to all for adding to the discussion. Special thanks to Michael for the tip on using a repeating date field for the key and to Beverly for the tip on handling ISO dates in FM. That has got me thinking about the whole ISO date scenario now.

I thought to start with Beverly's amendment to the function and to my surprise it all started to evaluate consistently!

A slight amendment to Beverly's calc was required though because DateCur needs a day value of 1.

I am glad you got it working. However, I refuse to believe in miracles. Your modified calculation will produce exactly the same result as the original one. If the problem has gone away, it must be for some other reason - and I would expect it to reappear at some point in some form.

You still haven't told what is opposite this field on the other side of the relationship - and I repeat my warning against placing a list of dates converted to text inside a multi-line key.

I agree that the amendment made to the custom function should NOT have made any real difference but it did. Nothing else was changed to make it evaluate consistently in the Set Field step.

The other side of the relationship is 'Date ( Month ( Events::Date_Start ) ; 1 ; Year ( Events::Date_Start ) )' (as Date).

This provides a common key for every event in a particular month.

The result is to produce dynamically related values, limited to three months only, via 'JSON_Array ( List ( Events_MY::JSON ) )' where 'JSON_Array' is another custom function I wrote that creates a valid array from a list of JSON objects.

The solution is a Javascript calendar where all necessary buttons are hooked up via script callbacks to update this 'list of three dates' key as needed.

The reason for all this is to avoid a performance hit no matter how many events build up in the events table as it only needs to display three months of data around the day/week/month you are on. The above custom function seemed to be the only way I could evaluate correctly across years. Hope all this also explains why d should = 1.