Why do Discord timestamps use Unix time instead of a date?

Because a Discord message is read by people in different timezones. A Unix timestamp is an absolute instant, so Discord can render it in each viewer's own local time and language. If you type a date and time as plain text, every reader has to convert it themselves.

Why does my timestamp show the wrong year?

Almost always because milliseconds were used instead of seconds. Discord expects Unix seconds, a 10-digit number. JavaScript and many APIs produce milliseconds, a 13-digit number, which Discord reads as a date tens of thousands of years in the future.

What is the difference between t, T, d, D, f, F and R?

They control how much of the date is shown. t is the time only, T the time with seconds, d a short numeric date, D a long written date, f the short date with time, F the long date with weekday and time, and R a relative phrase such as in 2 hours which updates as time passes.

Does the R relative format update by itself?

Yes. Discord recalculates relative timestamps when the client renders them, so a message saying in 2 hours will later read 2 hours ago without the message being edited.

Discord Timestamp Generator

What the markup actually is

The format is <t:UNIX:STYLE> — a literal <t:, then a Unix timestamp in seconds, then a colon, then a one-letter style, then >. Everything else is Discord's job.

The reason it exists is timezone. If you type “raid starts at 9pm” into a message, every reader has to work out what 9pm means for them. A timestamp is an absolute instant, so Discord renders it as each viewer's own local time — the same message reads “9:00 PM” to someone in London and “5:00 AM” to someone in Tokyo, without you doing anything.

The seven styles

Code	Shows	Example shape
`t`	Short time	9:01 PM
`T`	Long time (with seconds)	9:01:42 PM
`d`	Short date	11/28/2026
`D`	Long date	November 28, 2026
`f`	Short date and time	November 28, 2026 9:01 PM
`F`	Long date, weekday and time	Saturday, November 28, 2026 9:01 PM
`R`	Relative	in 2 hours / 3 days ago

The exact wording depends on the reader's client language, so the examples above show the shape, not the literal string. f is the one to use for events, because it gives both date and time in the shortest readable form. F is best when the day of the week matters.

The milliseconds mistake

This is the failure behind almost every “my timestamp is wrong” question. Unix time exists in two conventions:

Seconds — a 10-digit number, what Discord expects. 1700000000 is November 2026.
Milliseconds — a 13-digit number, what JavaScript's Date.now() and most APIs return. 1700000000000.

Feed Discord 13 digits and it does not complain — it just reads the number as seconds, which lands you tens of thousands of years in the future, and the timestamp renders as an absurd date. This page accepts both: if the number is larger than a hundred billion it is treated as milliseconds and divided by a thousand, and it tells you when it did that, so the conversion is never silent.

One second is the whole resolution. Unix time counts whole seconds, so a timestamp cannot express half a second. If you need “9:01:42.500”, Discord timestamps are the wrong tool — nothing you do with the markup will preserve the fraction.

Relative timestamps change by themselves

R is the odd one out: it is not a fixed string. Discord recalculates it when the message is displayed, so a message that says “in 2 hours” will say “2 hours ago” later, with no edit. That makes it ideal for countdowns and deadlines, and terrible for anything that needs to stay literally true — a screenshot of an R timestamp is only accurate on the day it was taken.

One practical consequence: you cannot pre-compute what an R timestamp will say. You can only compute the instant it points at, which is what this tool gives you.

Where timestamps work, and where they do not

Work: normal messages, embeds, and most text fields Discord renders as markdown.
Do not work: places that are not rendered as message content — channel names, role names, and plain-text contexts outside Discord.
Edge case: Discord's own embed timestamps (the small grey time in an embed footer) are set through the API, not by writing <t:…> into text.

Frequently asked questions

Can I use a negative timestamp?

Unix time counts from 1 January 1970, so dates before that are negative. Discord will accept the number, but very old dates are rarely what you want and some clients render them oddly — if you are testing, start from a date you can verify.

Does the timestamp respect daylight saving time?

Yes, automatically, because it stores an absolute instant rather than a wall-clock time. That is exactly why it is more reliable than writing “3pm” in a message: during a DST change, the same stored instant maps to different wall-clock times for different readers, and Discord handles that conversion.

Why does my date show the previous day?

Because your timestamp was created for a different timezone than the one reading it. Midnight UTC is still the previous evening in the Americas. Nothing is broken — the stored instant is correct, and each reader sees their own local equivalent.

Do I need a bot to use these?

No. The markup is typed as ordinary text and rendered by the client. A bot is only needed if you want to send timestamps programmatically or build them from slash commands.

Sources

The <t:UNIX:STYLE> syntax and the seven style letters — Discord's own message formatting documentation for developers, checked 25 October 2026.
Official documentation — discord.com/developers

Nothing on this page is sent anywhere — the conversion runs in your browser. Nothing is stored either.