Discord Timestamps: Syntax, Styles and Examples

Posting "the event starts at 8 PM" in a server with members on several continents guarantees confusion. Discord solves it with a small piece of markup: write the moment as a Unix timestamp inside <t:...>, and each reader's Discord client shows it converted to their own time zone and formatted for their locale. You type one value; everyone sees the right local time.

The syntax

A timestamp has two forms:

<t:TIMESTAMP>
<t:TIMESTAMP:STYLE>

TIMESTAMP is Unix time: the number of seconds since 1 January 1970 UTC, such as 1790892000. STYLE is a single letter that picks the format. Leave it out and Discord uses f, so <t:1790892000> and <t:1790892000:f> display the same way. The letter is case-sensitive: d and D are different styles.

Every timestamp style

Discord's developer documentation lists nine styles. The names and sample outputs below are the ones given there. Many older guides list only seven styles and leave out s and S.

The examples describe a pattern, not the exact text every reader sees. Discord states that timestamps are displayed in the user's time zone and locale, so the order of day and month, the separators, the month names and the 12- or 24-hour clock all vary from reader to reader. R is calculated when the message is viewed, which makes it the style to use for countdowns and deadlines: a future time reads as something like "in 3 hours".

One number, every time zone

A Unix timestamp identifies a single instant, not a wall-clock time. 1790892000 is 22:00 UTC on 1 October 2026, and a timestamp built from it shows each reader their own local time:

The conversion on the reader's side is automatic. The only place errors creep in is on yours: turning "6 PM in New York" into the right number in the first place.

Getting the Unix timestamp

The quickest way is the Timestamp Converter. If the event is at a time on your own device, open its Discord tab, pick the date and time or press Use Current, and the table gives every style at once: the Style name, the finished <t:...> under Code with a Copy button, and a Looks like preview. That tab reads the time in your own device's zone and ignores the Time zone menu, so when the event is planned elsewhere, work the number out first:

1. Choose the time zone the event is planned in from the Time zone menu. It starts on your own zone and lists the IANA zones your browser supports, such as America/New_York.
2. In the Date → Timestamp panel, pick the date and time and click Convert.
3. Copy the Seconds value, not the Milliseconds value, and paste it into <t:...:F> or whichever style you want.
4. To double-check, paste the number into the Timestamp → Date panel and read it back in UTC, in any zone and as a relative time.

The toolbar also shows the current Unix timestamp with a Copy button, which is handy for "posted at" or "starting now" messages. For a whole schedule, the Batch tab takes one timestamp or date per line, up to 500, and Copy as CSV hands the table to a spreadsheet. The Code tab writes the conversion of the timestamp on screen in eight languages, PowerShell not among them. In code, these all produced 1790892000 for 6 PM on 1 October 2026 at UTC−4 (New York summer time):

// JavaScript
Math.floor(Date.now() / 1000)                          // now, in seconds
Date.parse('2026-10-01T18:00:00-04:00') / 1000         // 1790892000

# Python
import time
from datetime import datetime, timedelta, timezone
int(time.time())                                       # now, in seconds
int(datetime(2026, 10, 1, 18, 0,
    tzinfo=timezone(timedelta(hours=-4))).timestamp()) # 1790892000

# Linux shell (GNU date)
date +%s
date -d '2026-10-01 18:00 -0400' +%s                   # 1790892000

# PowerShell
[DateTimeOffset]::UtcNow.ToUnixTimeSeconds()
[DateTimeOffset]::new(2026, 10, 1, 18, 0, 0, [TimeSpan]::FromHours(-4)).ToUnixTimeSeconds()

A fixed offset like -04:00 is only right for part of the year. New York switches to UTC−5 on 1 November 2026, so for dates after that the same wall-clock time needs -05:00. Converting with a named zone avoids the problem: the converter's zone menu does, and so does zoneinfo.ZoneInfo("America/New_York") in Python. On Windows, Python needs the tzdata package for that; without it we got ZoneInfoNotFoundError.

Examples you can paste

Maintenance starts <t:1790892000:F> (<t:1790892000:R>).
Tournament check-in closes at <t:1790892000:t>.
Applications are open until <t:1790892000:D>.

Combining a full date with a relative time, as in the first line, gives readers both the exact moment and how long they have. To show the markup itself instead of a rendered date, for example when explaining it to other members, wrap it in backticks so Discord displays it as code.

Common mistakes

• Milliseconds instead of seconds. JavaScript's Date.now() returns milliseconds, currently 13 digits; Unix time in seconds is 10 digits until the year 2286. Read as seconds, 1790892000000 is a date more than 50,000 years away. Divide by 1000 and round down.
• Parsing a date without a time zone. In JavaScript, new Date('2026-10-01T18:00') uses the time zone of the machine running the code, which on a hosted bot is often UTC rather than yours, while a date-only string such as '2026-10-01' is read as midnight UTC. Always include an offset or convert with a named zone.
• Converting in the wrong zone. If you plan an event for 20:00 in Berlin but convert 20:00 in your own zone, every reader sees a shifted time. Set the converter's zone to where the event is planned.
• Trusting PowerShell's Get-Date -UFormat %s. In Windows PowerShell 5.1 on a UTC+4 machine it returned a value four hours off, with a decimal fraction. Use [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() instead.
• Mixing up style letters. f and F, t and T, d and D and s and S are all different, so check the letter case when the output looks longer or shorter than expected.