| Unix timestamp (seconds) | 86,400 |
|---|---|
| In milliseconds | 86,400,000 |
| UTC date & time | Friday, January 2, 1970, 00:00:00 UTC |
| Day of week (UTC) | Friday |
| ISO 8601 | 1970-01-02T00:00:00Z |
| RFC 2822 | Fri, 02 Jan 1970 00:00:00 +0000 |
| Your local time | — |
| Day of year | Day 2 of 1970 (365 days) |
| ISO week | 1970-W01 |
| Days since epoch | 1 full days exactly |
| Julian Date | JD 2440588.50000 |
| Hexadecimal | 0x00015180 |
| Binary (32-bit) | 00000000 00000001 01010001 10000000 |
| Read as milliseconds | Thursday, January 1, 1970, 00:01:26 UTC — the classic off-by-1000 mistake |
| 32-bit signed | Fits in a signed 32-bit integer with 2,147,397,247 seconds (68 years, 17 days) to spare before the 2038 limit. |
| Previous milestone | 0 (The Unix Epoch) is 1 days earlier |
| Next milestone | 1000000 (One Million Seconds) is 10.6 days later |
What does the timestamp 86400 mean?
The number 86,400 is as much a unit fact as a date. As a Unix timestamp it points to exactly 86,400 seconds — one full day — after the Unix epoch — Friday, January 2, 1970, 00:00:00 UTC — which makes it a perfect teaching example for how seconds accumulate since the epoch.
The value 86,400 is famous in its own right: it is the number of seconds in a 24-hour day (60 × 60 × 24). As a timestamp it lands precisely one day after the epoch, making it a handy sanity check that a system is counting seconds, not milliseconds.
Why 86400 matters
The number 86,400 appears in more source code than almost any other time constant, usually spelled 60 * 60 * 24 or SECONDS_PER_DAY, and this page is what it looks like when that constant is treated as a timestamp: exactly one day into the Unix era, midnight UTC on Friday, January 2, 1970. It makes a convenient sanity check. If a converter hands you 00:00:00 on January 2, it is reading seconds; if it hands you 00:01:26 on January 1, it has been given milliseconds and is off by a factor of one thousand. It is also worth remembering what 86,400 does not promise. Unix time counts every day as exactly 86,400 seconds, but civil days are not so tidy. On the day clocks spring forward a local calendar day lasts 82,800 seconds, on the day they fall back it lasts 90,000, and on each of the 27 occasions so far when a leap second has been inserted, the UTC day was 86,401 seconds long. Unix time papers over all of that by repeating a second at each leap second, which is why "add 86,400" is the right way to move one Unix day but the wrong way to move one calendar day in a zone with daylight saving.
The exact value, every way you need it
A Unix timestamp is a single integer: the count of seconds elapsed since the Unix epoch (midnight UTC on January 1, 1970), ignoring leap seconds. The value 86,400 seconds is the same instant as 86,400,000 milliseconds — the form most programming languages expect, since JavaScript, Java, and many databases store time in milliseconds. Written out in full it is Friday, January 2, 1970 at 00:00:00 UTC, which is a Friday. In the two most common machine-readable formats it is 1970-01-02T00:00:00Z (ISO 8601) and Fri, 02 Jan 1970 00:00:00 +0000 (RFC 2822). All of these describe one and the same moment in time; they differ only in notation.
How to convert 86400 in code
Turning this timestamp into a human-readable date takes a single expression in most languages. In JavaScript, remember to multiply by 1000 because Date works in milliseconds: new Date(86400 * 1000).toUTCString(). Here are the equivalents in three common environments:
// JavaScript const ts = 86400; const date = new Date(ts * 1000); // JS uses milliseconds console.log(date.toUTCString()); // Fri, 02 Jan 1970 00:00:00 GMT console.log(date.toISOString()); // 1970-01-02T00:00:00Z
# Python 3 from datetime import datetime, timezone ts = 86400 print(datetime.fromtimestamp(ts, tz=timezone.utc)) # 1970-01-02 00:00:00+00:00
# Bash / GNU date date -u -d @86400 # Fri, 02 Jan 1970 00:00:00 UTC # macOS / BSD date date -u -r 86400
If you would rather not write code at all, the Epoch Converter is pre-loaded with 86400 so you can see it converted instantly and tweak the value live.
How long ago (or how far away) is it?
The headline near the top of this page updates every time you load it, computing the gap between 86400 and your current clock in real time so it never goes stale. To measure the span between this timestamp and any other date precisely — in years, months, weeks, days, or business days — use the Date Duration Calculator. To watch a future moment tick down second by second, the Countdown Timer can target this exact instant.
Why timestamps matter
Storing time as a plain integer of seconds is wonderfully unambiguous: there is no time zone, no daylight saving, and no locale to misinterpret. Two servers anywhere on Earth agree on what 86400 means. That is why logs, databases, JWTs, file metadata, and APIs lean on Unix time so heavily. The trade-off is that the number is not human-friendly at a glance — which is exactly the gap a reference like this page fills.
Related timestamps
Other notable Unix timestamps worth a look:
- 2147483647 — The Y2038 Limit0 — The Unix Epoch1000000 — One Million Seconds1000000000 — One Billion Seconds