A Discord timestamp not working almost always comes down to one of five problems, and every one of them has a quick fix. Maybe your timestamp claims the event happens in the year 58,000. Maybe Discord is showing the raw <t:...> code as plain text. Maybe the time renders, but it's the wrong hour. This guide walks through each failure the way you'd actually debug it: what you're seeing, what causes it, and exactly how to fix it.
Before anything else, know the shape of a healthy timestamp: <t:1784194890:F>, which is a lowercase t, a 10-digit Unix timestamp in seconds, and one of seven style letters, all inside angle brackets. If yours doesn't match that shape, you've probably already found your bug. If you'd rather skip debugging entirely, our timestamp generator produces known-good codes with a live preview.
Quick Diagnosis Table
| What you see | Most likely cause | Fix |
|---|---|---|
| A date in the year 58,000+ | Milliseconds pasted instead of seconds | Divide the number by 1000 |
Raw <t:...> text in chat | Backticks, a syntax typo, nesting, or a bad style letter | See the four causes below |
| Renders, but the hour is "wrong" | Expecting the sender's timezone | Nothing; it shows each viewer their local time |
| "in 5 minutes" seems off or stale | Device clock skew | Sync the device clock |
| Works in chat, breaks in a bot embed | Timestamp placed in the wrong embed part | Put the code in the description or field values |
Now the details, because the second problem in particular has four distinct causes.
Problem 1: The Date Shows a Year Like 58,491
What you see: The timestamp renders, but it points to a date tens of thousands of years in the future.
The cause: You pasted a millisecond timestamp where Discord expects seconds. Unix time counts seconds since January 1, 1970 UTC, and a current date is a 10-digit number like 1784194890. But JavaScript's Date.now(), most APIs, and plenty of database exports hand out 13-digit millisecond values like 1784194890000. Discord doesn't validate the magnitude; it just treats your milliseconds as seconds, which lands you roughly 56,000 years too far into the future. Hence the year 58,000-something.
The fix: Divide by 1000 and drop the decimals. 1784194890000 becomes 1784194890. The quick sanity check: if the number has 13 digits, it's milliseconds; 10 digits is seconds and correct for any date in our lifetime. Our unix converter accepts either and always outputs Discord-ready seconds, so it's the easy way to launder suspicious numbers.
Problem 2: Discord Shows the Raw <t:...> Text
What you see: Instead of a rendered time in a highlighted box, your message displays the literal code, angle brackets and all.
This one has four separate causes. Check them in order, because they all produce the identical symptom.
Cause A: The code is wrapped in backticks or a code block
Inline code and code blocks tell Discord's markdown engine to render contents literally. That's their entire job. So `<t:1784194890:F>` displays the raw code on purpose. This bites people who copy timestamps out of tutorials (where they're deliberately shown as code) along with the backticks.
Fix: Remove the backticks or triple-backtick fences around the timestamp. The code should sit in the message as bare text.
Cause B: There's a typo in the syntax
The parser is strict. Any of these kills the render: a missing angle bracket, a space anywhere inside (<t: 1784194890:F>), an uppercase prefix (<T:...>), a missing colon, or stray characters like commas in the number (<t:1,784,194,890:F>).
Fix: Compare your code character by character against the pattern <t:NUMBER:LETTER>. No spaces, no punctuation in the number, lowercase t prefix. Keep our format code reference open if you write these by hand often.
Cause C: The timestamp is nested inside a link or heading
Discord markdown won't render a timestamp inside a masked link like [event time](<t:1784194890:F>), and timestamps inside heading lines (# Starts <t:...>) misbehave too. The same applies to a code straddling bold or italic markers, where the ** or * lands partway through the token: the parser sees broken pieces of both.
Fix: Move the timestamp out into plain body text. Formatting around the whole code is fine (**<t:1784194890:F>** works); formatting through the middle of it is not.
Cause D: The style letter is invalid
The only valid style letters are t, T, d, D, f, F, and R, and they're case-sensitive. <t:1784194890:r> with a lowercase r, or an invented letter like x, won't render.
Fix: Use one of the seven valid letters, or omit the style entirely; <t:1784194890> falls back to the default f (short date/time) rendering.
Problem 3: The Timestamp Renders, But the Time Looks Wrong
What you see: You created a timestamp for 8 PM, and a member reports it says 5 PM. Or you posted it, checked on another device, and saw a different hour.
The cause: Nine times out of ten, nothing is broken. Discord timestamps render in each viewer's own timezone, not the sender's. You made it for 8 PM your time; your West Coast member sees 5 PM because that's the same moment where they live. This is the entire point of the feature, but it surprises people constantly, usually when they compare screens with someone in another timezone or check their own message while traveling.
The fix: First, confirm it's actually correct: the time shown to each person should be your intended moment converted to their zone. If it genuinely is wrong for everyone, then the Unix timestamp itself encodes the wrong moment, which usually means the tool that generated it assumed the wrong source timezone. Regenerate the code with our timestamp generator, which uses your device's local timezone, and double-check the preview before copying.
One related admin mistake: don't write "<t:1784194890:t> EST" in announcements. The label is wrong for every viewer outside EST, because the rendered time next to it is already localized. Let the timestamp stand alone.
Problem 4: Relative Time Seems Stale or Slightly Off
What you see: A relative timestamp reads "in 3 minutes" when it should say "in 5 minutes," or a countdown appears frozen or ahead of reality.
The cause: Relative (R) timestamps are computed against the viewer's device clock. If that clock has drifted, every relative timestamp in Discord drifts with it. A phone that's two minutes fast makes every countdown look two minutes short. This is client clock skew, not a Discord bug and not a problem with your code.
The fix: Enable automatic time synchronization on the device (Date & Time settings on Windows, macOS, iOS, and Android all have a "set automatically" toggle). If a member reports weird countdowns that nobody else sees, their clock is virtually always the culprit. Fully closing and reopening a long-idle Discord client can also nudge a stubborn stale render.
Problem 5: Timestamps in Embeds vs Plain Messages
What you see: Your timestamp works fine in a normal message, but breaks or shows raw text when a bot posts it inside an embed.
The cause: Embeds have their own structure, and dynamic timestamps only render in the parts of an embed that process markdown. If your bot puts <t:...> into an embed title, author line, or footer text, it will display as raw code. The footer's dedicated timestamp property is also a different thing entirely: it takes an ISO 8601 value and renders a static localized time, not the <t:...> syntax.
The fix: Bots must place the plain <t:1784194890:F> syntax inside the embed description or field values, which are the markdown-rendered regions. Same syntax as a normal message, no extra encoding. If you're building announcement embeds, generate the code with the timestamp generator and drop it straight into the description string.
Prevention: Habits That Keep Timestamps Working
Most of these failures never happen if you build three small habits:
- Generate, don't hand-type. Copying from a generator with a live preview eliminates typos, wrong style letters, and the seconds-versus-milliseconds trap in one move. Hand-writing codes is where nearly every Problem 1 and Problem 2 case starts.
- Preview before you post, verify after. A generator preview shows the render before you paste; after posting, hover the timestamp on desktop (long-press on mobile) and check the tooltip's full date. Ten seconds total, and it catches wrong-day and wrong-year mistakes before your members do.
- Never add timezone labels. Any text like "EST" or "CET" next to a dynamic timestamp will be wrong for most viewers. If you feel the urge to add one, that's usually a sign you haven't fully trusted the localization yet. Trust it; it works.
Teach these to your mod team once and your #announcements channel stays clean permanently.
Still Broken? Run It Through the Generator
If you've checked all five problems and something still looks wrong, stop hand-writing the code. Open our timestamp generator, pick your moment, and copy a fresh code from the live preview, which shows exactly what Discord will render before you paste anything. For suspicious numbers coming out of APIs or spreadsheets, the unix converter will tell you instantly whether you're holding seconds or milliseconds. Two minutes of tooling beats twenty minutes of squinting at angle brackets.