Your Discord bot's timestamp says the year 58970 (I tested 16 edge cases)
Discord turns <t:1798765200:F> into a date shown in each reader's own time zone. The format is documented, but what Discord does with bad input isn't. Bots generate these strings, and bots get the input wrong, so on 4 No
Discord turns <t:1798765200:F> into a date shown in each reader's own time zone. The format is documented, but what Discord does with bad input isn't. Bots generate these strings, and bots get the input wrong, so on 4 November 2026 I sent 16 malformed or extreme codes to a private server from the Discord web client and read back what rendered.
| Code | What it tests | Discord showed |
|---|---|---|
<t:1798765200:F> |
Normal | Friday, January 1, 2027 at 6:30 AM |
<t:1798765200000:F> |
Milliseconds by mistake | Tuesday, August 7, 58970 at 9:30 PM |
<t:0:F> |
Zero | Thursday, January 1, 1970 at 5:30 AM |
<t:-86400:F> |
Negative | Wednesday, December 31, 1969 at 5:30 AM |
<t:2147483648:F> |
One past the 32-bit limit | Tuesday, January 19, 2038 at 8:44 AM |
<t:8640000000000:F> |
Largest JavaScript date | Saturday, September 13, 275760 |
<t:8640000000001:F> |
One second past that | raw text |
<t:0001798765200:F> |
Leading zeros | renders normally |
<t:1798765200> |
No style letter | same as f
|
<t:1798765200.5:F> |
Decimal | raw text |
<t:+1798765200:F> |
Plus sign | raw text |
<t: 1798765200:F> |
Space | raw text |
<t:1798765200:X> |
Unknown style | raw text |
(Times are as shown to a reader in UTC+5:30. Raw data: results.json.)
The one that bites: milliseconds render
Almost every invalid input fails loudly: the reader sees <t:…> as raw text and someone reports it. Milliseconds don't fail. Date.now() in JavaScript and System.currentTimeMillis() in Java return milliseconds. Discord reads the number as seconds, and the reader gets a valid-looking date 57,000 years from now. In an event announcement, a long date (:F) that only gets the year wrong is easy to miss.
// wrong: Date.now() is milliseconds
`<t:${Date.now()}:F>`
// right
`<t:${Math.floor(Date.now() / 1000)}:F>`
Python's time.time() and datetime.timestamp() return seconds as a float, so the bug there is the decimal: f"<t:{time.time()}:F>" gives <t:1798765200.123:F>, which shows as raw text. Wrap it in int().
The limits match JavaScript's Date
The upper bound isn't 2038 and it isn't 64 bits. 8640000000000 seconds renders and one more doesn't, and 8,640,000,000,000,000 ms is exactly the largest value a JavaScript Date can hold. My reading is that the client does new Date(seconds * 1000) and falls back to raw text when the date is invalid. That's an inference from the boundary, not something Discord documents.
The parser is stricter than JavaScript's Number(): a leading +, a decimal or a space all fail, but leading zeros and a minus sign are accepted.
A guard for bot code
function discordTimestamp(unix, style = 'f') {
if (!Number.isInteger(unix)) throw new TypeError('whole seconds only');
if (Math.abs(unix) >= 1e11) unix = Math.floor(unix / 1000); // looks like milliseconds
return `<t:${unix}:${style}>`;
}
1e11 seconds is the year 5138, so anything that large is almost certainly milliseconds. The same heuristic is used in the converter on discordtimestampgen.com, which also has a JSON API that returns all seven formats.
Where it doesn't render at all
Even a valid code shows as raw text in some places: poll questions and answers, thread titles, server nicknames and custom status (all measured on web the same day). It does render in messages, thread messages and channel topics. I didn't test bot embeds or the mobile apps, which may differ.
Full table and method: Discord timestamp not working?
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.