Discord Timestamp Generator

How to use it

1. Pick a date and time, or press “Use now” to start from the current moment.
2. Check the timezone. We detect yours. This is the timezone you are entering the time in, not the one your readers will see.
3. Copy the code you want and paste it straight into a Discord message.

What you paste is not what anyone sees. Discord replaces the code with a formatted time when the message posts.

The seven formats

Every format is the same instant written differently. The letter after the colon picks which one.

Leave the style off — just <t:1786894200> — and Discord uses f.

Note that the date formats above are shown as a British reader would see them. An American reader’s client writes 08/16/2026 for the same code, without either of you doing anything. That is not a setting you control, and it is the feature rather than a bug.

Why other people see a different time

This is the question behind almost every search for Discord timestamps, and it has a satisfying answer.

The number inside the code is a Unix timestamp — a count of seconds since 1 January 1970 UTC. It refers to one specific instant, the same instant everywhere on Earth. It carries no timezone because it does not need one.

When Discord renders it, each client converts that instant into its own local time. So if you schedule a raid for <t:1786894200:F>:

Nobody converts anything. Nobody gets it wrong. Notice that Tokyo is on the next day — the kind of mistake that regularly costs a raid group an hour, handled automatically.

This is why writing “8pm EST” in a message is worse than useless for an international server. Half your readers do the conversion wrong, and a quarter don’t know whether you meant EST or EDT.

Relative timestamps

The R format is the one most people are actually looking for, and it does something the others can’t: it stays correct.

A message saying “event at 4:30 PM” is stale the moment the event passes. A message with <t:1786894200:R> reads “in 3 hours”, then “in 20 minutes”, then “2 hours ago”, updating on its own. For pinned announcements and scheduled events that is the difference between a message that ages well and one that misleads people a week later.

The wording follows fixed thresholds:

The units round rather than truncate, so 90 minutes shows as “in 2 hours”, not “in 1 hour”.

Putting one in a message

Paste the code as ordinary text. No formatting, no code block, no escaping:

Raid starts <t:1786894200:F> — that's <t:1786894200:R>

Posts as: Raid starts Sunday, 16 August 2026 4:30 PM — that’s in 3 hours.

Pairing an absolute format with a relative one is the pattern worth copying. The first tells people exactly when, the second tells them how soon, and both stay right for every reader.

One thing to watch: if you put the code inside a code block with backticks, Discord shows the raw text instead of rendering it. That’s occasionally useful for showing someone the syntax, and otherwise it’s the reason your timestamp “isn’t working”.

Where they work and where they don’t

Worked example

You’re organising an event for 8:30 PM on 16 August 2026, and you’re in London. Your server has people in California and Sydney.

1. Set the date to 2026-08-16 and the time to 20:30, timezone Europe/London.
2. The Unix timestamp comes out as 1786908600.
3. Copy the F code and the R code.

Your Californian members see 12:30 PM the same day. Your Sydney members see 5:30 AM on Monday the 17th — and now they know to argue with you about the time before it’s too late, which they could not have done from “8:30pm UK time”.

Reading a code someone else posted

The conversion runs both ways, and going backwards is more common than you’d think — someone posts <t:1786894200:F> in a channel and you want to know what it means without waiting for Discord to render it, or you’re reading a bot’s source, or a log file.

The number is all that matters. Everything else is presentation. So <t:1786894200:F> and <t:1786894200:R> point at the same instant and differ only in how it’s written.

To decode one by hand: take the digits between the colons, and that’s the Unix timestamp. Feed it into any epoch converter, or set the date and time on this page until the Unix line matches.

A rough sanity check without any tool at all: a ten-digit number beginning 17 is somewhere in the mid-2020s, and one beginning 16 is the early 2020s. That’s usually enough to know whether a timestamp is in the past or the future before you convert anything.

Why isn’t my timestamp working?

Four causes cover essentially all of it.

• It’s inside backticks. A code block shows the raw text on purpose. Take the backticks off.
• You’re in a place that doesn’t render them. Channel names, server names and usernames show the code as text. See the table above.
• The angle brackets are missing or mangled. The syntax is <t:1786894200:R> — both brackets, a lowercase t, a colon before the number and another before the style letter. Copying from a website that “helpfully” converted the brackets to HTML entities is a common way to lose them.
• You used milliseconds instead of seconds. This is the one that produces a wrong answer rather than no answer, so it’s worth its own section.

Seconds, not milliseconds

Discord wants seconds. JavaScript’s Date.now() gives milliseconds. Paste one where the other belongs and you get a date roughly fifty thousand years away, which Discord will render without complaint.

The quick check: a current Unix timestamp in seconds is ten digits. Thirteen digits means divide by a thousand and drop the remainder.

Discord won’t warn you about this, because a timestamp fifty thousand years out is technically valid. The failure is silent, and the only symptom is a date nobody notices until someone scrolls back and asks why the raid is scheduled for the year 58594. If a date looks absurd rather than merely wrong, count the digits first.

Generating them in code

If you’re writing a bot rather than a message, you want the number rather than this page.

Then build the string as <t:{seconds}:R>. discord.js has no dedicated helper worth learning — string interpolation is the whole job.

One caution for bots: if you’re storing a future event time, store the Unix seconds, not a formatted string. The moment you store “8:30 PM” you’ve thrown away the timezone and re-created the problem timestamps exist to solve.

Timestamps or scheduled events?

Discord has a separate Scheduled Events feature, and they solve different problems.

A scheduled event is an object in the server. It sends reminders, tracks who’s interested, and appears in the events list. Use it for anything recurring or anything you want people to opt into.

A timestamp is just text in a message. It does nothing except display correctly. Use it inside announcements, replies, and any sentence where a time appears.

They work well together: create the event, then write the announcement with a relative timestamp so the countdown is right for everyone reading it.

Dates before 1970

Unix time counts from 1 January 1970, so anything earlier is a negative number. Discord handles it, and so does this tool — <t:-86400:D> renders as 31 December 1969. It’s a curiosity rather than a feature, but it doesn’t break, and some tools do break on it.

The relative format copes too, so a historical date reads as “57 years ago” rather than counting forwards. If you’re posting about anything before 1970 and a generator refuses the date or silently clamps it to the epoch, that’s the tool’s limitation rather than Discord’s.

Related tools

Discord timestamps are Unix timestamps underneath, and the same instant drives scheduled jobs — the cron expression generator shows the next ten times a schedule fires, in a timezone you name. To see what one time is across several places at once without posting anything, use the time zone converter. For counting the gap between two dates, the date duration calculator handles it, and the business days calculator does the same while skipping weekends and holidays. If you need to read the raw bytes of a bot payload, the hex, binary and ASCII converter decodes them.