Discord Timestamp stops live update under 1 minute
Description
I am using <t:unix:R> Discord Timestamp in my Embed
The timestamp sometimes pauses/stucks at time 59 seconds
Although the timer itself still counting down and do the expected action when it reaches 0 seconds but it doesn't show me the exact seconds like 59 -> 58 -> 57 ...etc
Library used: Discord.py
Steps to Reproduce
- Create a Discord.py bot
- Create an Embed with a timestamp: <t:Unix:R>
- Check the timer when it is less than 1 minute
Expected Behavior
I expect the timestamp to show me the exact seconds like 59 -> 58 -> 57 ...etc
Current Behavior
the timestamp once becomes less than 1 minute it stucks at second 59 or 58
Screenshots/Videos

Client and System Information
Client: Discord Desktop application OS: Windows 11 Library: Discord.py
The issue is happening on mobile aswell (IOS) (I see this since around june something like that) App version : 300.0 (85590) ptb Its happening on stable aswell
This was stuck at 7mn and when the time is reach its stuck at same time
The timestamp is correct with t:R
(embed)
Its only working if ur restarting ur app and u never switch (channels/or even messages)
I have Windows 10 and I can't reproduce the error
I am guessing you are viewing a timestamp that starts at >5m in length and not navigating away, just watching it tick down.
We try to limit the amount of updates that are rendered for timestamps. As such, unlike the relative values that are sub 60s and update every second, values that are closer to 5 minutes get an update every minute. The larger that diff gets, the longer the update interval becomes for performance reasons.
However it looks like we don't change the update interval as the diff changes over time.
So if you view a timestamp at >5min diff, then the update interval is set to 1minute and will remain that even as the diff decreases.
The fix here is to update the alg to be aware of the changing diff and adjust the update interval as the diff changes. No update on when this will be fixed as it is a low priority bug that is solvable by navigating away and back again (or refreshing), but it is in the backlog now.
For mobile, that uses a different system. It wouldn't surprise me if, due to performance optimizations, mobile does do any active updating.
I am guessing you are viewing a timestamp that starts at >5m in length and not navigating away, just watching it tick down.
The timer was set for 3 minutes