Database table to keep track of objects
It is quite common to copy the data as it stands at the point in time that a transaction occurred - in your case the Settings when a FoodMaker made something.  This happens with financial systems a lot for audit and reporting purposes.  Yes, it is duplication, but in a known and controlled way for a purpose.

The alternative is to add time range columns to Settings.  These delimit the interval in which those settings values are applicable.  The third table must hold the datetime when a row is inserted to it, as you propose.  When you read you add the predicate

.. and Third.date_time &gt;= Settings.FromDateTime and Third.date_time &lt; Settings.ToDateTime


With this approach you have to be very careful to never update values in Settings, only ever the ToDate, or insert whole new rows.  Ensuring there are no gaps or overlaps in these time ranges can be tricky, too.  Frequent changes to Settings can cause this table to bloat, slowing down the transactional part of your application.  Eventually you will want to purge old Settings which will fragment the table.

With a separate audit table containing snapshots of values most of these concerns go away.  You can deny all UPDATE activity on it, allowing only INSERTS so there is no risk of history changing.  The table can be partitioned by date allowing for fast purging.  Indeed, the whole table can be removed to a separate data mart for long-term storage and reporting.