// knowledge base

Unix Timestamps: The Complete Guide to Epoch Time

What is a Unix timestamp?

A Unix timestamp — also called epoch time or POSIX time — is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, a moment known as the Unix epoch. It is stored as a plain integer, with no timezone, no formatting, and no ambiguity. For example, 1767225600 always means the same instant everywhere on Earth: midnight UTC on 1 January 2026.

This simplicity is exactly why timestamps dominate computing. Comparing two moments is a single integer comparison. Sorting events is a numeric sort. Storing a date costs 4–8 bytes instead of a 25-character string. APIs, databases, log files, file systems, JWT tokens, and caching headers all speak epoch time because it removes an entire category of parsing bugs. When you see a 10-digit number like 1700000000 in a JSON response, you are looking at 14 November 2023 — and a converter like the one above turns it into a human date in one step.

Why 1 January 1970?

The date was chosen by the engineers building Unix at Bell Labs in the early 1970s. They needed a convenient round starting point for timekeeping, and 1 January 1970 was recent enough that 32-bit counters would last decades, yet early enough to cover the useful history of computing. The choice stuck: the C standard library, POSIX, and eventually nearly every operating system and programming language adopted the same origin. Today the epoch is baked into JavaScript's Date, Python's time module, Java's Instant, Go's time.Unix, and SQL functions like FROM_UNIXTIME(). Changing it now would break the world, so 1970-01-01 is effectively permanent.

Seconds, milliseconds, microseconds, nanoseconds

The original definition counts seconds, producing 10-digit values (currently around 1.78 billion). But modern systems often need finer precision, so the same epoch is also counted in smaller units:

The digit-length rule is the fastest way to identify a unit: 10 → seconds, 13 → milliseconds, 16 → microseconds, 19 → nanoseconds. Epochly applies exactly this heuristic automatically, so you can paste any of the four without selecting anything. The most common bug in timestamp work is mixing seconds and milliseconds — if your date lands in the year 55,000, divide by 1,000; if it lands in 1970, multiply by 1,000.

How to convert a timestamp to a date (and back)

Converting epoch to date is a division problem; converting date to epoch is about pinning a calendar moment to the UTC timeline. In JavaScript: new Date(1767225600 * 1000) for seconds, or new Date(1767225600000) for milliseconds. In Python: datetime.fromtimestamp(1767225600, tz=timezone.utc). In a terminal: date -d @1767225600 -u on Linux. Going the other way, JavaScript's Math.floor(date.getTime() / 1000) gives epoch seconds, and Python's int(dt.timestamp()) does the same.

Two details matter. First, confirm the unit before converting — the digit rule above. Second, decide which timezone the displayed result should use. The timestamp itself is always UTC; only its rendering changes. Epochly shows UTC, your local time, ISO 8601, the weekday, and a relative phrase ("3 days ago") side by side so nothing is left ambiguous.

The timezone trap (and how to avoid it)

Nine out of ten "my timestamp is wrong" reports are timezone confusion, not bad data. A Unix timestamp has no timezone — it is a single point on the global timeline. The confusion appears when software displays it: midnight UTC on 1 January 2026 is still 31 December 2025 in New York and already morning in Tokyo. If your conversion is off by exactly your UTC offset (5:30 for India, 5:00 for US Eastern in winter), the timestamp is fine and the display timezone is the culprit.

Defensive habits: store and transmit timestamps in UTC always; convert to local time only at the final display step; when debugging, compare the UTC rendering, not the local one; and remember daylight-saving shifts can inject a one-hour surprise twice a year in regions that observe it. When Epochly converts a date to a timestamp, it lets you declare whether the input means local time or UTC — that single toggle eliminates the most common direction of the bug.

Y2K38: the 2038 problem

Systems that store Unix time in a signed 32-bit integer hit a wall at 2147483647 — 03:14:07 UTC on 19 January 2038. One second later the counter overflows into negative numbers and clocks jump back to December 1901. It is the same class of bug as Y2K, but harder to fix because the vulnerable counters hide in embedded controllers, old file formats, legacy databases, and binary network protocols rather than in visible date fields.

Modern 64-bit operating systems, languages, and databases already use 64-bit time and are safe for billions of years. The risk sits in long-lived infrastructure: industrial controllers, automotive firmware, medical devices, and archived data formats designed decades ago. If you maintain such systems, audit every place a 32-bit time_t or 32-bit timestamp column appears, and migrate storage to 64-bit integers well before 2038. The live countdown above shows exactly how much runway remains.

Famous epoch milestones

Certain timestamps have become landmarks: 0 (the epoch itself, 1970-01-01), 1000000000 (the billion-second party, 2001-09-09), 1234567890 (2009-02-13), 1500000000 (2017-07-14), 2000000000 (2033-05-18), and 2147483647 (the 32-bit limit). Developers use them as test fixtures and Easter eggs; the reference table above renders each one and loads it into the converter on click.

Discord timestamps: dynamic dates for every viewer

Discord supports a special syntax — <t:UNIX_TIMESTAMP:STYLE> — that renders as a date in each reader's own timezone. Post <t:1767225600:F> and an American sees "Wednesday, December 31, 2025 7:00 PM" while an Indian sees "Thursday, January 1, 2026 5:30 AM", both correct. It is the cleanest way to announce event times to a global audience.

All seven styles: t short time (4:20 PM), T long time (4:20:30 PM), d short date (1/1/2026), D long date (January 1, 2026), f short date/time (the default when no style is given), F full date/time with weekday, and R relative ("in 3 days" / "2 hours ago" — it even updates live on Discord). The timestamp must be whole seconds, not milliseconds. Epochly's Discord studio builds the tag, previews every style instantly, and copies it to your clipboard.

Where timestamps hide in everyday tech

Once you recognize epoch time, you see it everywhere. HTTP cache headers (Expires, Last-Modified), JWT exp claims, OAuth token lifetimes, database created_at columns, file modification times, GPS and telemetry logs, analytics event streams, and certificate validity windows all use it. Log forensics is a major use case: paste a column of epoch values into the batch converter above and an unreadable wall of numbers becomes a readable timeline in seconds — invaluable when correlating incidents across services that log in different units.

Leap seconds: the asterisk on epoch time

Strictly, Unix time ignores leap seconds: every day is defined as exactly 86,400 seconds, and the occasional leap second inserted into UTC is simply not counted. That means Unix timestamps drift from true solar time by the accumulated leap seconds (currently 27). For everyday software this is irrelevant, but it matters for astronomy, satellite navigation, and precise scientific measurement, which use TAI or GPS time instead. If you need sub-second legal-time accuracy across leap-second boundaries, convert via a leap-second table rather than raw arithmetic.

Best practices for working with epoch time

  1. Store UTC, display local. Keep one canonical integer; localize only at render time.
  2. Use 64-bit integers for storage. Never store epoch seconds in a 32-bit column in new systems.
  3. Be explicit about units in APIs — name fields created_at_ms or document "epoch seconds" so consumers never guess.
  4. Prefer ISO 8601 strings (2026-01-01T00:00:00Z) in human-facing APIs; reserve raw integers for machine-to-machine paths.
  5. Validate ranges on input: reject negative values or absurd far-future dates where they make no sense for your domain.
  6. Test the 2038 boundary if your stack touches 32-bit time anywhere, including serialized data and third-party libraries.

Epoch time has survived more than five decades because it is the smallest possible honest representation of "when". Whether you are debugging a log, scheduling a Discord event for a worldwide community, or auditing a system for Y2K38, the converter above handles every unit, every direction, and every edge case — instantly, privately, and free.