This is diametrically opposed to the advice to never store booleans, but rather store enums.<p>Experience shows that the initial assumption of two states (false, true) often requires a third, or even fourth, fifth state etc. added down the road. (Business-logic states like "reserved", "pending", "in progress", "confirmed", "processed", etc.)<p>As long as these states are mutually exclusive, it's far more elegant to add another enum value rather than new fields.<p>So no, don't timestamp it. Stick to enumerated values rather than booleans, which will generally be of far greater benefit.<p>If you need to store a log of actions, then create that explicitly. Otherwise, it seems pretty silly and arbitrary to have booleans record their timestamp but not strings, integers, etc.<p>Edit in response to comments below: of course there are times when you need values that <i>aren't</i> mutually exclusive, so obviously you add another column. It's just that you very often <i>do</i> add another state that <i>is</i> mutually exclusive, and so using an enum keeps your data cleaner, more intuitive, and prevents accidental invalid combinations of booleans as well.