On thinking further about DST and the computer situation, I suspect that the astronomy example is probably contrived, as all calculations would likely be done in UCT and then only translated to local if needed.

However, I would expect that there would be cases where it would be necessary to calculate the correct local time of day at some time in the past, which would require that such calculations properly take into account changes in the DST rules over time.

The example that popped into mind had to do with an audit or dispute of the response time for a support call that had been handled in the past.  Consider that some support contracts have limitations on when support is provided and how long the company has to respond with a callback to the caller.  As an example, let’s assume that a contract specifies that a caller has support during normal business hours in their own timezone (e.g. 8:00am-5:00pm in the Central timezone) and is entitled to a callback within 2 business hours.  This means that if the caller opens a problem at 4:00 PM Central, then the company has to respond by 9:00 AM the next business day.  So if a caller comes back at some later time in the future to dispute the call and claim that the contract conditions were not met because the callback was late, it would be necessary to correctly translate the timestamps (problem open time, callback time) from UTC to the local timezone to determine if the contact conditions were actually met or not.  It is often the case that callers misunderstand the contract terms and complain about expectations not being met, which could possibly result in the company giving back revenue if the actual times are not properly calculated.