Epoch/Timestamp Converter

The number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — the "Unix epoch." It's a single number that unambiguously represents a specific moment in time, independent of timezone, which is exactly why it's used so widely in APIs, databases, and log files.

By the number's magnitude. A current seconds-based timestamp is 10 digits; a current milliseconds-based one is 13. This tool checks whether the value is large enough to only make sense as milliseconds, and treats it as seconds otherwise — covering both formats without needing you to specify which one you're pasting.

No — just seconds and milliseconds, the two formats actually used by JavaScript's Date object and most common APIs. Some other converters support microsecond (16-digit) or nanosecond (19-digit) precision, typically used by databases like PostgreSQL or specific logging systems; this tool doesn't handle those.

A real limitation of systems that store a Unix timestamp as a signed 32-bit integer: that format runs out of room at 03:14:07 UTC on January 19, 2038 — the next second, it overflows and wraps around to December 1901. It only affects older 32-bit systems and anything explicitly using a 32-bit time field; modern 64-bit systems (which is most of them today) use a 64-bit counter that won't overflow for billions of years, so this tool and your browser aren't affected.

new Date(timestamp * 1000) if your value is in seconds (JavaScript's own Date object always expects milliseconds) — literally the same approach this tool's own code uses internally. If your value is already in milliseconds, skip the multiplication: new Date(timestamp).

datetime.fromtimestamp(timestamp) from the datetime module, using a seconds-based value. For a UTC result specifically rather than your system's local time, use datetime.fromtimestamp(timestamp, tz=timezone.utc).

It's genuinely different per database: MySQL uses FROM_UNIXTIME(timestamp); PostgreSQL uses TO_TIMESTAMP(timestamp). Both expect a seconds-based value, not milliseconds.

=UnixTimestamp/86400+25569, formatted as a date. Excel uses a completely different epoch (January 1, 1900, with its own well-known quirk of treating 1900 as a leap year), so the formula divides by 86400 to convert seconds into days, then adds 25569 — the fixed number of days between Excel's epoch and the Unix epoch — to line the two systems up.

They're the exact same instant in time, just displayed in two different timezones: UTC shows it in Coordinated Universal Time (no offset), while Local shows it converted to your own device's timezone setting.

A human-friendly way of expressing how far the given timestamp is from right now — in the past ("ago") or the future ("in"), automatically picked in whichever unit (seconds, minutes, hours, days, months, or years) reads most naturally.

Yes — a negative Unix timestamp represents a moment before the epoch, and this tool handles that correctly, resolving to the right date before January 1, 1970.

Yes — it updates every second automatically, no refresh needed.

Yes — use the date & time picker instead of the epoch field; it produces the same set of output formats.

No — every conversion happens instantly in your browser. Nothing you enter or paste is sent to a server.

Unix timestamp and epoch timestamp are two names for exactly the same thing — the number of seconds since January 1, 1970 UTC. This tool handles both directions of that single concept.

Convert your date or epoch value as normal, then copy the "Paste into Discord" field — it's a ready-to-use <t:seconds:style> tag. Paste it directly into a Discord message and Discord renders it as a live, auto-updating timestamp, automatically shown in each reader's own timezone. Use the style buttons (t/T/d/D/f/F/R) to pick short time, long time, short date, long date, short date+time, long date+time, or relative ("in 3 hours") — f (short date/time) is Discord's own default if you omit the style. A live "Renders in Discord as" preview updates as you switch styles, so you can see exactly what each one produces before copying it — you don't need to already know what the letters mean.

Yes — the number itself carries no timezone at all; it's just a count of seconds since a fixed point, and represents the exact same instant everywhere in the world. UTC only comes into play when you convert that number into a human-readable date: at that point, you choose which timezone to display it in (that's exactly why this tool shows both a UTC and a Local result for the same timestamp).

Related, but not the same concept. UTC is a time *standard* — a way of expressing a specific date and time. Unix time is a *counting system*: a single number of seconds elapsed since a fixed reference point (Jan 1, 1970 UTC). A Unix timestamp is always computed relative to UTC, but the number itself isn't "in" any timezone the way a calendar date and time are.

Not directly — "Local" always reflects your own device's timezone setting, not a timezone you choose. If you need a specific timezone other than your own or UTC, convert to UTC here first, then apply that timezone's offset yourself (for IST specifically, that's UTC+5:30).

It was a practical, fairly arbitrary choice by early Unix developers at Bell Labs, not a deep technical requirement — they needed a fixed, recent reference point and picked one that was convenient to work with given the era's tiny amounts of computer memory. (The very first version of Unix actually used 1971 as its reference point, measured in 1/60ths of a second; when it was redesigned to count whole seconds instead, the reference point was moved back to the cleaner, rounder January 1, 1970.)

JavaScript: Math.floor(Date.now() / 1000) for seconds, or just Date.now() for milliseconds. Python: import time; int(time.time()). PHP: time().

Milliseconds — Date.now() (and every other JavaScript Date method) always works in milliseconds since the epoch, never seconds. If you need a standard 10-digit Unix seconds value, divide by 1000 and round down: Math.floor(Date.now() / 1000).

date("Y-m-d H:i:s", $timestamp) — the date() function formats a Unix timestamp (in seconds) into a readable string using that format-code syntax. Leave the second argument off entirely and it formats the current time instead, equivalent to calling time() first.

A common JavaScript-specific gotcha, not a bug in this tool: Date.prototype.getMonth() returns a zero-indexed value (0 for January, 11 for December), unlike getDate() (day of month) or getFullYear(), which aren't zero-indexed. If you're building your own date-handling code alongside this tool, remember to add 1 when displaying a JavaScript-derived month number to a user.