How Many Seconds Are In 24 Hrs

You’re sitting there, maybe staring at a countdown timer, maybe trying to debug a script that uses epoch time, or maybe you just woke up at 3 AM with a random question stuck in your head. How many seconds are in 24 hrs?

The short answer is 86,400.

But if you only take that number and walk away, you’re missing the context that actually makes it useful. So the number changes — sometimes. Day to day, the definition of a second isn’t what you learned in school. And if you’re writing code, managing servers, or doing any kind of data analysis, the "obvious" answer is the one that breaks things.

Let’s unpack it.

What Is a Second, Really

Most of us grew up with the idea that a second is 1/86,400 of a mean solar day. That’s the old definition. But it’s intuitive. The Earth spins once, that’s a day. Chop it into 24 hours, each hour into 60 minutes, each minute into 60 seconds. Done.

Except the Earth is a terrible clock. It wobbles. It slows down. Tidal friction from the Moon drags on the rotation. In real terms, big earthquakes shift mass around and actually change the length of a day by microseconds. If you define the second based on the Earth’s rotation, your second gets longer over time. That’s unacceptable for GPS, for telecommunications, for particle physics, for basically everything modern.

So since 1967, the second has been defined by the cesium atom. Specifically: the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom.

That’s the SI second. It’s constant. It doesn’t care about the Earth’s mood.

The math that gets you to 86,400

It’s just multiplication. But let’s write it out because the steps matter when you’re debugging.

• 60 seconds in a minute
• 60 minutes in an hour → 3,600 seconds in an hour
• 24 hours in a day → 3,600 × 24 = 86,400 seconds

That’s the civil* day. The mean solar* day. The one your wall clock tracks (mostly).

Why It Matters / Why People Care

You might wonder why anyone writes a whole article about a multiplication problem. Also, real outages. Here’s why: the difference between "86,400" and "the actual number of seconds today" causes real bugs. Real data corruption.

The leap second problem

Because the SI second is fixed and the Earth’s rotation isn’t, they drift apart. To keep civil time (UTC) aligned with the Sun — so noon is roughly when the Sun is highest — we occasionally insert a leap second.

That means a day in UTC can be 86,401 seconds long. Or, theoretically, 86,399 seconds (a negative leap second, though that’s never happened yet).

Since 1972, there have been 27 positive leap seconds added. Plus, nobody knows. The last one was December 31, 2016. The next one? The International Earth Rotation and Reference Systems Service (IERS) announces them about six months in advance.

If your system assumes every day is exactly 86,400 seconds, it will drift. In real terms, for a bank processing high-frequency trades, that’s a disaster. Slowly. Then suddenly you’re a second off. For a satellite navigation system, a one-second error puts you off by roughly 300 kilometers.

Unix time and the "seconds since epoch" trap

Developers love Unix time. It’s the number of seconds since January 1, 1970, 00:00:00 UTC. Simple. But portable. Universal.

Except Unix time ignores* leap seconds. Day to day, it pretends every day is exactly 86,400 seconds. When a leap second occurs, the Unix timestamp either repeats a second (23:59:59 happens twice) or the system smears the extra second over several hours (Google’s "leap smear" approach).

This means Unix time is not a true count of SI seconds elapsed. It’s a count of nominal* seconds. The difference matters if you’re calculating precise intervals across leap second boundaries.

Daylight saving time is not the same thing

People confuse leap seconds with daylight saving time (DST). They’re unrelated.

DST shifts the label* on the clock. The day still has 86,400 seconds (or 86,401 with a leap second). But in spring, the local clock jumps from 1:59 AM to 3:00 AM — that day only has 23 hours on the wall clock*. In autumn, you get 25 hours on the wall clock.

If you’re doing date math in local time, you cannot assume 24 hours = 86,400 seconds. You have to use UTC or a proper time zone database.

How It Works (or How to Calculate It)

Let’s break down the practical side. Now, you need the number of seconds in a day for different contexts. The formula changes.

For civil time (UTC) — most common case

Standard day: 86,400 seconds. Leap second day: 86,401 seconds (rare, announced in advance).

If you’re writing a cron job, a scheduler, or a daily rollover script, you usually want 86,400. But you must* handle the edge case where the day is longer. Most modern languages handle this if you use their standard libraries correctly.

For more on this topic, read our article on how many hours is 2000 minutes or check out how many ounces are in 9 cups.

For astronomical / scientific work

You need the exact* rotation angle of the Earth. Even so, that means UT1 (Universal Time based on Earth rotation), not UTC. Practically speaking, it’s published by IERS. Worth adding: the difference between UT1 and UTC is called DUT1. It’s usually within ±0.9 seconds.

For high-precision work — VLBI, satellite laser ranging, pulsar timing — you don’t use "86,400." You use the actual length of day (LOD) which varies daily by milliseconds.

In programming languages

Python

from datetime import timedelta
one_day = timedelta(days=1)
print(one_day.total_seconds())  # 86400.0

Python’s datetime module assumes 86,400 seconds per day. It does not represent leap seconds. If you need leap-second-aware timestamps, you need a specialized library like astropy.time or you handle it at the OS level (NTP with leap second smearing).

JavaScript

const msPerDay = 24 * 60 * 60 * 1000; // 86,400,000 ms

Date objects work in milliseconds. Same assumption: 86,400,000 ms per day. No leap seconds.

Go

day :=

```go
day := time.Hour * 24 // 24 * 60 * 60 * 1e9 nanoseconds = 86,400,000,000,000 ns
fmt.Println(day.Seconds()) // 86400

Go’s time package, like the others shown, treats a day as a fixed 24‑hour interval. It does not insert or remove leap seconds; the underlying system clock may smear or step, but the library presents a uniform civil day.

Rust

use chrono::{Duration, Utc};
let one_day = Duration::days(1);
assert_eq!(one_day.num_seconds(), 86_400);

The popular chrono crate follows the same convention. For leap‑second awareness you can switch to the tai crate, which provides TAI‑based timestamps where each day is exactly 86 400 SI seconds and leap seconds are exposed as explicit offsets.

C# / .NET

var oneDay = TimeSpan.FromDays(1);
Console.WriteLine(oneDay.TotalSeconds); // 86400

.NET’s DateTime and TimeSpan assume the civil day. If you need to work with UTC that includes leap seconds, you can use the NodaTime library, which offers an Instant type based on TAI and lets you query the IERS leap‑second table.

Handling leap seconds in practice

1. Prefer UTC for civil logic – most business rules (billing, logging, scheduling) are expressed in wall‑clock time. Use the standard library’s day length (86 400 s) and rely on the OS/NTP to apply the leap‑second smear or step transparently.
2. Isolate scientific code – when you need sub‑millisecond accuracy across a leap‑second boundary, work in a timescale that does not insert or delete seconds (TAI or GPS time). Convert to/from UTC only at the presentation layer, applying the latest DUT1/IERS bulletin.
3. Validate inputs – if you accept timestamps from external sources, check whether they are UTC, TAI, or a smeared variant. Misinterpreting a smeared timestamp as a true UTC value can introduce errors of up to half a second over the smear window.
4. Test edge cases – schedule unit tests that simulate 23:59:59 → 23:59:60 → 00:00:00 transitions. Many languages provide mockable clocks (e.g., Python’s freezegun, Java’s Clock) that let you inject a leap‑second day without waiting for the real event.

Quick checklist for developers

• ☐ Use the language’s built‑in duration/timespan for “one civil day” = 86 400 s.
• ☐ Switch to a specialized library (astropy, NodaTime, tai, etc.) when you need true SI‑second accounting.
• ☐ Keep a copy of the latest IERS leap‑second table (or rely on the OS’s tzdata) for any conversion between UTC and TAI/GPS.
• ☐ Document whether your APIs expect UTC, TAI, or local time, and state explicitly how leap seconds are handled.
• ☐ Review any cron‑like schedulers: they usually fire every 86 400 s; verify that your scheduler’s internal clock is not disrupted by a leap‑second step or smear.

Conclusion
While the everyday answer to “how many seconds are in a day?” is simply 86 400, the reality is richer. Leap seconds occasionally stretch a civil day to 86 401 seconds, and the Earth’s variable rotation makes the true length of a day fluctuate by milliseconds. Most programming languages and libraries deliberately hide this complexity, presenting a stable 86 400‑second day for civil timekeeping. When your application demands astronomical precision or must remain unambiguous across a leap‑second boundary, step outside the standard date‑time primitives and adopt a timescale‑aware library (TAI, GPS, or specialized astronomical packages). By keeping civil‑time logic in UTC with the conventional day length and reserving high‑precision work for a leap‑second‑free timescale, you avoid subtle bugs while still being prepared for the rare moments when the universe adds—or subtracts—a second.