For Developers

Why Discord and Slack Timestamps Just Work

A message can show '3:00 PM' to someone in New York and '8:00 PM' to someone in London, from the exact same text. Here is the trick behind it.

Anyone who's scheduled something across timezones has felt the pain of writing "let's meet at 3 PM my time" and hoping the other person does the math correctly. Discord and Slack both solved this with a small piece of message markup that looks unremarkable but does something genuinely useful: it lets the same message render a different, correct local time for every single reader.

The mechanism, not the magic

Both platforms work the same underlying way: the message contains a raw Unix timestamp — a plain number, with no timezone attached at all — plus a format code describing how it should be displayed. When a reader's client renders the message, it takes that timezone-agnostic number and formats it using the reader's own device timezone setting. The cleverness isn't in the storage; a Unix timestamp is about as simple as data gets. It's in deferring the timezone conversion all the way to the final rendering step, on the reader's own device, instead of baking in a specific timezone when the message is written.

Discord's version

Discord uses a tag like <t:1750000000:F>, where the number is a Unix timestamp in seconds and the letter controls the display style — short time, long date, a relative "in 3 hours" style, and a few others. Anyone can generate this manually, but getting the syntax exactly right without a tool is fiddly enough that a dedicated Discord Timestamp Generator is worth using instead of writing the tag by hand.

Slack's version

Slack's equivalent is denser: <!date^1750000000^{{date_num}} at {{time}}|fallback text>. The token string in the middle controls formatting using named placeholders instead of a single-letter code, and the text after the final pipe is a fallback shown to any client that doesn't support the dynamic format at all — a detail that's easy to forget when building the tag by hand.

Why this pattern is worth copying elsewhere

The underlying idea — store a plain, timezone-agnostic Unix timestamp, and only decide how to display it at the very last step, using whoever's actually looking at it right now — is good general advice for any software that shows dates to people in different timezones, not just chat apps. It's the same principle behind storing everything in UTC and converting only for display, applied specifically to text-based messages.

Related

Related tools & reading