Currently, the only Airtable field with persistence is CREATED_TIME(). Accordingly, the only real way to keep track of changes to {Date Due} — that is, the only cybernetic, rather than procedural, way — would be to make {Date Due} a linked-record field. You could then use a roll-up field with a MAX(values) aggregation function to identify the last date set. (That assumes {Date Due} is only changed to a later date; if it can go both ways, there’s still a way to determine it, based on CREATED_TIME() of the last change.) This would give you a count of how many times {Date Due} has been changed and the date and time of each change.
As I recall, I used this technique in tracking what I call ‘outs’ in my Wardrobe Manager base. Since an item can be sent out (for cleaning, repair, or to be used) multiple times, I needed a way to reflect that. My use is a little more complex than yours, as I needed to track status, due date, and restoral date and reason for each out, but the basic code should be similar.
