<story><title>You might as well timestamp it (2021)</title><url>https://changelog.com/posts/you-might-as-well-timestamp-it</url></story><parent_chain></parent_chain><comment><author>jpollock</author><text>The problem with the timestamp is that it keeps people from thinking that they&amp;#x27;ve got an enum.&lt;p&gt;For example, let&amp;#x27;s start with an object, which has a boolean flag &amp;quot;active&amp;quot;.&lt;p&gt;boolean is_active;&lt;p&gt;We will always want to get a bit more advanced, and get into sub-states as it is brought up. We can&amp;#x27;t do that with a boolean. So we go to an enum.&lt;p&gt;Enum current_state {
  not_configured;
  being_provisioned;
  active;
  disabled;
  deleted;
}&lt;p&gt;current_state state;&lt;p&gt;We have an enum in hiding. Converting the boolean to a timestamp stops the conversion to an enum - we can&amp;#x27;t overload the presence of a timestamp into the multiple values in the enum.&lt;p&gt;The timestamp is &amp;quot;what happened, when&amp;quot;, an audit log&amp;#x2F;change history function. That should be kept separate from the rest of the database.&lt;p&gt;Sometimes, there is a business reason to track a timestamp - charge the customer 30days after the item became &amp;quot;active&amp;quot;. 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.</text></comment>
<story><title>You might as well timestamp it (2021)</title><url>https://changelog.com/posts/you-might-as-well-timestamp-it</url></story><parent_chain></parent_chain><comment><author>simonw</author><text>This was one of Luke Plant&amp;#x27;s YAGNI exceptions: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;lukeplant.me.uk&amp;#x2F;blog&amp;#x2F;posts&amp;#x2F;yagni-exceptions&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;lukeplant.me.uk&amp;#x2F;blog&amp;#x2F;posts&amp;#x2F;yagni-exceptions&amp;#x2F;&lt;/a&gt;</text></comment>