Dev.to WebDev 🛠 Dev 👁 0 📖 3 min read

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?

📰 Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.