The DNS server is free to do it as often as it wants/needs: signatures liftetime is a policy issue, covered by a DPS (DNSSEC Policy Statement). You can find examples and good practices, but if a server wants to create signatures even on the fly, it can (see https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html "In PowerDNS live signing mode, signatures, as served through RRSIG records, are calculated on the fly, and heavily cached." or https://www.cloudflare.com/dns/dnssec/dnssec-complexities-and-considerations/ "Cloudflare’s DNSSEC implementation leverages ECDSA’s efficient signature generation to sign DNSSEC records on-the-fly.")
Signatures in RRSIG records have two dates: a beginning of validity and an end.
This has nothing to do with the TTL value, nor the zone changes (signatures will change even if the zone does not change).
See for example in A Framework for DNSSEC Policies and DNSSEC Practice Statements section 4.6.5. "Signature Lifetime and Re-Signing Frequency" that mandates a good policy document to have:
This subcomponent describes the life cycle of the Resource Record
Signature (RRSIG) record.
Now let us look at some published DPS:
17.6 Signature Life-time and Resigning Frequency:
The KSK signatures of the TLD zone DNSKEY RRset will have a validity period of 40 days.
The ZSK signatures of the TLD zone authoritative data will have a validity period of 10 days
(default TTL: 86400s aka 1 day)
We re-sign our zones daily with a signature lifetime of 30 days.
(default TTL: 3600s aka 1 hour)
RR sets are signed with ZSKs with a validity period of fourteen days and are resigned every two days.
Zone file generation and the signing of new records takes place every hour.
(default TTL: 3600s)
The signing practice of the COM Zone is divided into quarterly continuous time cycles of approximately 90 days. Time cycles begin at the following dates each year:
January 15th
April 15th
July 15th
October 15th
The time cycle will never be less than 90 days, except in emergency situations (in which a key has been compromised) or if Verisign decides to begin using different key lengths.
(default TTL: 172800s aka 2 days)
etc.
Also, take into account this part from RFC 4035 (section 5.3.3):
If the resolver accepts the RRset as authentic, the validator MUST
set the TTL of the RRSIG RR and each RR in the authenticated RRset to
a value no greater than the minimum of:
o the RRset's TTL as received in the response;
o the RRSIG RR's TTL as received in the response;
o the value in the RRSIG RR's Original TTL field; and
o the difference of the RRSIG RR's Signature Expiration time and the
current time.