Why Is My Discord Timestamp Not Working?
If a timestamp is showing raw text, the wrong time, or nothing at all, it's almost always one of these five causes.
1. Milliseconds instead of seconds
Discord expects Unix seconds, not milliseconds. If your number is 13 digits long (something like 1735689600000) instead of 10 (1735689600), that's the problem — many programming languages' default "current time" functions return milliseconds. Discord doesn't reject it: in our test, <t:1798765200000:F> rendered as August 7, 58970, so it looks like a working timestamp with an absurd year. Fix: drop the last three digits, or divide by 1000 before formatting the code. The Unix timestamp converter detects and corrects this automatically if you paste the raw number in.
2. Malformed brackets or an invalid format letter
Discord only recognizes the exact pattern <t:UNIXTIME:FORMAT> — a smart/curly quote substituted for an angle bracket, a missing colon, or a letter outside t T d D f F R will make Discord display the raw text unchanged instead of a formatted timestamp. Fix: regenerate the code with the generator rather than hand-editing a previous one, and paste it without any auto-formatting from another app.
3. It's not wrong — it's showing the reader's own time zone
This is the single most common thing mistaken for a bug. A Discord timestamp always renders in each reader's own local time zone, not the zone it was created in. If you set 3 PM Eastern and a friend in London sees 8 PM, both of you are seeing the correct, converted time — nothing needs fixing.
4. Your system clock was off when you generated it
If you used a "current time" preset while your device's clock was skewed, the resulting timestamp will be genuinely off by that same amount for everyone, in every time zone. Fix: confirm your system clock is correct (most devices sync automatically, but virtual machines and some Linux setups can drift), then regenerate.
5. The wrong UTC offset around daylight saving
A Unix timestamp is a fixed moment, and Discord converts it to each reader's offset for that date, so a daylight-saving change never moves a correct timestamp. The mistake happens when the code iscreated: converting "8 PM New York" with a fixed offset like UTC−5 gives the right answer in January but is an hour off in July, when New York is on UTC−4. Fix: convert with a named time zone (America/New_York), not a fixed offset. The time zone converter does this for the date you pick.
Where timestamps work, and where they don't
Many "not working" reports are really about where the code was pasted. We tested the same codes in different places on Discord's web client on 4 November 2026:
| Where | Renders? |
|---|---|
| Normal message | Yes |
| Message inside a thread | Yes |
| Channel topic | Yes |
| Poll question and poll answers | No, raw text |
| Thread title | No, raw text |
| Server nickname | No, raw text |
| Custom status | No, raw text |
So for a poll or a thread, put the timestamp in the message that goes with it. We didn't test bot embeds. Raw results: surfaces.json.
What Discord actually accepts: our test
On 4 November 2026 we sent 16 timestamp codes to a private Discord server from the web client and recorded which ones Discord formatted. Times below are as shown to a reader in India (UTC+5:30).
| 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 (before 1970) | Wednesday, December 31, 1969 at 5:30 AM |
<t:2147483648:F> | Past the 2038 limit | Tuesday, January 19, 2038 at 8:44 AM |
<t:8640000000000:F> | Largest date JavaScript allows | Saturday, September 13, 275760 at 5:30 AM |
<t:8640000000001:F> | One second past that | Raw text |
<t:0001798765200:F> | Leading zeros | Friday, January 1, 2027 at 6:30 AM |
<t:1798765200> | No style letter | January 1, 2027 at 6:30 AM (same as f) |
<t:4102444800:R> | Relative, far future | in 73 years |
<t:1798765200.5:F> | Decimal seconds | Raw text |
<t:+1798765200:F> | Plus sign | Raw text |
<t: 1798765200:F> | Space after the colon | Raw text |
<t:1798765200:X> | Unknown style letter | Raw text |
<t:1798765200000000000:F> | 19-digit number | Raw text |
So Discord accepts any whole number of seconds from far before 1970 up to the year 275760, with or without leading zeros. It shows raw text for decimals, signs, spaces, unknown letters and anything out of range. The dangerous case is milliseconds: it does render, just thousands of years in the future. Raw results: results.json. We tested the web client; mobile apps may differ.
Still not working?
Regenerate the code from scratch using the tool below rather than editing an old one by hand — it guarantees correct syntax and seconds-based Unix time every time. For background on how the mechanism works at all, see how Discord timestamps work.