It is important to remember that trust is generally inherited. Code signing certificates with time stamping 'solve' the problem of expiring code-signing certificates by instructing the software to check with that the code-signed certificate was valid at the time it was signed. So, someone with the original private key needs to be answering where the software checks.
In order to trust what the server of the original signing party says, a valid chain of trust is still required. The end-use public certificate generated to establish specific attributes like "I am the code-signing server of the COMODO RSA Certification Authority" is itself signed by the private key of an intermediate public certificate, continuing in a chain of trust back to a root certificate which signed by the key of a public certificate on a relatively short list trusted by the environment a program is running in -- generally the root certificate trust store of the OS or a specific root trust store built in to that software.
A timestamped code-signing certificate still requires that a chain of trust is established in communicating with the party who has the private key of the time-stamped code-signing certificate. The intermediate and root certificates are generally created with a much longer validity period (in the 10-40 year range), but over a long enough time frame all currently-available trust chains will expire unless the root trust store is updated.
Since your trust store is not generally filled with very new root certificates, this is also a moving target and it is not uncommon for an OS only a few years old to begin to encounter trust chain problems unless updates are installed. This is why Safari on say, your relative's 2016-vintage macbook running OSX 10.12 Sierra that has been EOL since 2019 will say a lot of websites are untrusted -- Safari is looking at a stale trust store from 2019 or earlier.