I actually left the date format field alone. This shouldn't make any difference, but my created_at time's format is the following: 2024-12-10T18:17:00.233Z
Thank you for trying to replicate it @MiguelOrtiz . It sparked a theory that panned out.
The root cause is "dirty" data. Unix time was stored as a string, not a number.
If you feed the table unix time as a number, it recognises it properly and respects column formats.
If you feed the table iso time as a string, it works as expected.
However if you feed it unix time as a string, it's smart enough to interpret it and display it as a date, but not smart enough to group against it.
Taking a guess, the grouping is done off the source data?
If you cannot correct it at the source and need a quick fix, something like {{ item * 1 }} in the table converts it into a number for the table to interpret correctly.
I don't know if this is a bug/feature request going forward, but it would be nice if the table could handle unix time as a string gracefully.
So, this morning I was working with groupings myself, focusing on the sorting (I had custom sorting in my data source but grouping defaults sorting to either Ascending or Descending). When I changed the values of my columns using "mapped value" the sorting changed, which makes me thing grouping isn't using source data, rather the values as rendered by the table (unless grouping and sorting use different data source as reference, but that is unlikely).
Thank you both for sharing your troubleshooting process! Marking @ferret141's answer as a solution, so that it is visible to others. It looks like our team is further researching the way the table handles unix timestamps