I have a formula column that uses the max date of subitems. It used to work flawlessly, but now fails for items that have more than one subitem.
It may be coincidental, but it appears to have broken with the introduction of the new datepicker.
Here’s a simplified example:
Hi, I’ve the exact same issue. It’s works fine until this afternoon.
I’ve the new datepicker since a few day but it was working good.
Everything seemed to be working this morning but this when I’ve reload my board this afternoon, this issue append.
Same problem over here. They seem to have changed the data type of subitem dates summaries. Now it seems to be outputting an array of values instead of only the max value, hence the formula no longer working. You can verify that by creating a new formula “{SubitemsDateMax}” (with the double quotes), the output will be a list of comma separated numbers representing the different dates of your subitems.
I’ve been trying to find a workaround for over an hour but no luck so far.
Edit: I found a workaround 
In your subitems, add a new formula column
DATEVALUE({Your_Date_Column})
Then make a summary of those subitems at item level, set it to MAX.
Then create a new formula at item level
FORMAT_DATE({Your_Summary_Date_Column},“YYYY-MM-DD”)
This will get you your max date in the right format, so you can use this column in other formula columns.
Edit 2:
There seems to be a weird thing happening when converting a date to numerical value and converting it back to date format. The final date is 1 day earlier than it should. This can be easily fixed by adding 1 in the formula.
Also, the formula will return 1899-12-30 if the value is 0, so can tweak the formula as such to return nothing instead.
IF({Date NumFormat Max}=0,“”,FORMAT_DATE({Date NumFormat Max}+1,“YYYY-MM-DD”))
The final output looks like this and works as intended.
Edit 3: If an item has no subitems, the formula will still return 1899-12-30 because the value in this case would be void, which is different from 0. To avoid that, you can add an OR statement inside your if as follows:
IF(OR({Date NumFormat Max}=0,{Date NumFormat Max}=NUMERAL(0)),“”,FORMAT_DATE({Date NumFormat Max}+1,“YYYY-MM-DD”))
Thanks Bob, your workaround works great ! 
The only modification I’ve done compare to you is that I don’t need to do the +1 day.
Converting to a number and set it back to date works fine to me (without the +1 day).
Hi Rémi, glad it worked for you!
And thanks for sharing that you don’t need the +1, it will be helpful for future readers.
My hypothesis is that it is caused by the difference in time zones. I guess you are in GMT+2, whereas I am in GMT-4.
If Monday initializes their day counter based on GMT+0 at 0:00 on 1899-12-30, it means that the counter actually initialized on 1899-12-29 for those living in negative time zones, hence the 1 day lag.
So to make it short, if your time zone is negative, add one day, if it’s positive it should give you the correct date right away.
Thanks for the solution Bob.
Out of interest, is there a way to reference the first/last item in the array that’s returned (I couldn’t find any documentation)? If so, could that be referenced to avoid the additional helper column?
Hi Gareth, that’s the first thing I tried, but unfortunately it doesn’t work for 2 main reasons.
The numbers in the array seem to be kind of in random order; the largest date is sometimes in the middle of the array. If the max would always be first/last, then you could LEFT or RIGHT function to only keep the first/last 13 digits number but unfortunately since numbers are in a nonsequential order you can’t know what number you’ll be extracting.
The output here is a 13 digit number, which is different from Monday’s number counter. So converting it back to a date with FORMAT_DATE didn’t seem to be working and I didn’t find any other formula that could convert that 13 digits format into date format.
I personally have over 50 boards to update because of that change on Monday’s side, so I’ll keep it on standby until Monday can tell us whether it’s a bug that will be fixed, or a new feature that’s working as intended.
Hi Bob,
FYI the date is a Unix timestamp. If I convert the values returned in the array, they correspond to the actual dates.
Using www.epochconverter.com, this gives me the following (if I use my time zone as you have previously pointed out):
1691622000000,
1694041200000,
1696460400000
Thursday, 10 August 2023 00:00:00 GMT+01:00 DST
Thursday, 7 September 2023 00:00:00 GMT+01:00 DST
Thursday, 5 October 2023 00:00:00 GMT+01:00 DST
Which means I can run this function:
ADD_DAYS("1970-01-01", right("{SubitemsDateMax}", 13)/86400000)
Which almost works - I just need to allow for the time zone.
This will fail where only one date is provided, so will need to be wrapped in an IF statement.
Of course, the best solution would be for Monday to fix the issue 
Oh that’s great!
If I may add to this, if you use max(args2array( it will ensure you’ll get the max value within the array. If the array is empty it will return 1970-01-01 instead of an error.
To avoid the 1970-01-01 to be displayed you can indeed wrap it in an if statement.
You can also wrap it in a format date formula to get a more standard date output.
My final formula looks like this
IF(max(args2array({SubitemsDateMax}))=0,“”,FORMAT_DATE(ADD_DAYS(“1970-01-01”, max(args2array({SubitemsDateMax}))/86400000),“YYYY-MM-DD”))
and the final output looks like this
Update: Monday once again managed to change the behaviour of that column without giving anyone a heads up, so this no longer works. The output value of subitem date summary column has been changed; it is no longer an array of timestamps, but a single 4 digits number that’s impossible to work with because different dates can have the same 4 digits number value.
This is too much of an unstable mess, I’ll just remove those columns from my boards and move on.
Just noticed the same. I too have resorted to removing the columns.
Surely Monday must recognise that they can’t change the behaviour of a column on a whim?
It’s all very frustrating.
