The problem with the timestamp is that it keeps people from thinking that they've got an enum.

For example, let's start with an object, which has a boolean flag "active".

boolean is_active;

We will always want to get a bit more advanced, and get into sub-states as it is brought up. We can't do that with a boolean. So we go to an enum.

Enum current_state { not_configured; being_provisioned; active; disabled; deleted; }

current_state state;

We have an enum in hiding. Converting the boolean to a timestamp stops the conversion to an enum - we can't overload the presence of a timestamp into the multiple values in the enum.

The timestamp is "what happened, when", an audit log/change history function. That should be kept separate from the rest of the database.

Sometimes, there is a business reason to track a timestamp - charge the customer 30days after the item became "active". How to model that depends on your database and what is required - history table, convert the enum to struct, time_became_active, time_of_last_state_change, etc.