Rollup - Latest incorrect

G’day Glideteam,

I believe there is a bug with the latest rollup function to grab the most recent date in the relation.
It probably has something to do with the dd/mm/yyyy vs mm/dd/yyyy format.

My sheet uses the dd/mm/yyyy format.
Because it’s a more logical format :slight_smile:

When there are two flippable dates (dates that can be interpreted as mm/dd or dd/yy depending on where you live) using the dd/mm/yyyy format =

06/01/2018 (6th Jan 2018) vs 01/06/2018 (1st June 2018), it will pick up 06/01/2018 instead as the latest.

I’m not sure what I should be looking for in your app. Sheet2 only shows the fruit name. Understandably, it’s probably a bug, but your safest bet would be to store dates or display them in yyyy/mm/dd. It might be different in the builder vs the published url too, so that’s something to check.

Ah - apologies, the app view wasn’t showing it correctly.
I’ve updated it now.

The first tab shows all records and the second tab shows the ‘Latest Records’ that was based on the Relation. Please see Apples and Grapes.

Bananas are to show that it’s correct when it’s not a flippable date.

1 Like

Maybe try adding a column in your sheet to act as a helper column, format the dates in Glide’s format. Use that as the column to Rollup.

If you’re having an issue with formatting the dates, a more complex workaround would be to use a DATEVALUE formula in that column. You’d then use this column to configure the maximum value for your Rollup column!

Just some alternatives!

This is a good fix, @MegannLock!

The ONLY caveat to this solution is if you’re looking for instant calculations/comparisons with dates for filtering/visibility purposes. The 5-10 second lag might be a deal breaker. Such was the case with my Meet with Me app.
Meet with Me: A Booking App that Prevents Conflicts

1 Like

Thank you for the suggestions!
Yes, my app needs instant calculations.

My workaround was eventually duplicating the column - one for the calculation and one for labelling.

I still believe this is a bug - since for non-flippable dates (e.g. 31/05/2020) it works correctly no matter how you record it.