Brute-force attacks are irrelevant. All remotely modern methods of cryptography, apart from the uses of passwords that can be memorized by humans, are way beyond reach of brute force. With a 128-bit key, if you could afford to set a billion computers to brute-forcing a key, and each computer could try a billion keys per second, and you were prepared to wait until the universe is twice the age it is now (about 30 billion years), you'd still have barely a 1% chance of success.
If large quantum computers are possible (which is not certain), they will effectively halve the key size for symmetric encryption, which makes 128-bit keys brute-forceable. But there is a very simple solution, which is to use 256-bit keys instead. Anyway the amount of data exchanged with the key is not relevant here.
Things change if you consider the risk of side channel attacks. Many side channels give the attacker only a little bit of information at a time about the key, and it takes repeated use of the key to make the side channel exploitable. So for this reason, you may want to limit the use of a key.
Another reason to limit the use of a key is that each message requires a nonce. Repeating nonces can be catastrophic. Depending on the algorithm, the size of the nonce may be somewhat limited. If you can ensure that nonces are sequential, the limit is so high as to be practically unlimited. But that can make it difficult not to repeat nonces, for example if the sender's hard disk fails immediately after sending a message and they have to restore data from a backup. To avoid this difficulty, it's common to use random nonces, but then you run into the birthday problem: an $n$-bit nonce is likely to repeat after as little as about $2^{n/2}$ messages. To avoid this kind of difficulties, communication protocols typically don't reuse the same message encryption key between sessions. Each session derives a new key from the original shared key. The original shared key is used as a key derivation secret, not as an encryption key.
Deriving a new key for each session is similar to your idea of varying the key based on the date. But there are two major differences. One difference is that there's no point in using the date, which is problematic because clocks aren't very reliable so you could end up with a disagreement about the date, or the date being repeated because a device has run out of battery and rebooted to “blinking 12:00”. Instead, just use a random nonce for each session, long enough that it's practically guaranteed to be unique, and send the nonce together with the data. The other difference is that key derivation doesn't just change a few bits of the result when one of the parameters changes. A key derivation function (KDF) ensures that if even a single bit changes in one of the inputs, the outputs are completely different. Given the output of a KDF, there's no way to find the inputs, or to find the output of the same KDF for a different nonce with the same master secret.
Furthermore many protocols use ratcheting: rather than keeping a long-term master secret and deriving all session keys from it, they calculate a new master key each time. This protects against attackers who record encrypted conversations in the hope to discover the key one day. If a participant erases old keys regularly and their key gets compromised one day, the attacker will be able to decrypt future conversations, but not past conversations, since it's impossible to find older keys from the current master key, only newer keys.
