Countdown Timer

Set a target date and time, press start, and watch the days, hours, minutes and seconds fall away one second at a time.

Count down to any date and time

Set a target moment and the timer ticks live. It keeps running while the tab is open, with no account and no notifications.

Target

Date

Time

Label (optional)

Event label

Time remaining

–

Pick a target date and time.

Ticks live once a second
Counts up after the target
Four one-click presets
Runs entirely in your browser

Built and maintained by the Time Calculator team · Published 14 January 2025 · Last updated 24 July 2026 · Reading time: 14 minutes

Quick answer

A countdown timer measures the gap between now and a target moment, and redraws that gap once a second so you can watch it shrink. It subtracts two timestamps rather than decrementing a counter, so the reading stays correct even if the page is hidden, the laptop sleeps or the browser slows the timer down. Once the target passes, the same subtraction returns a negative number and the timer counts up instead, marked with a plus sign.

remaining = target − now (in milliseconds) days = floor(remaining / 86,400,000) hours = floor(remaining / 3,600,000) mod 24 minutes = floor(remaining / 60,000) mod 60 seconds = floor(remaining / 1,000) mod 60

What a countdown timer does

Two moments, one length. The first moment is right now, taken from your device clock and refreshed every tick. The second is the target you typed in. The countdown is nothing more than the distance between them, expressed in the largest units first so that a long wait reads as days rather than as an unhelpable pile of seconds.

The timer on this page reports that distance nine ways at once. Four fields split it into days, hours, minutes and seconds, which is how people say it out loud. Four more give the same interval as a single total in hours, in minutes, in seconds and in weeks, which is how you use it for planning: if there are 720 hours left before an exam, you can divide that into revision blocks in a way you cannot do with "30 days". The ninth field is a status, either counting down or elapsed, so you know which direction the numbers are moving.

You can also give the target a label. A bare set of digits is easy to misread when you have two of them open in different tabs, and "Product launch" or "Thesis due" above the numbers removes the ambiguity. The label does not change any arithmetic. It just tells you which moment you are looking at.

Four presets fill the target for you. Next New Year jumps to the first instant of the coming January. In 1 week, in 30 days and in 24 hours each take the current moment and push it forward by a fixed span, which is the fastest way to start a timer when the exact calendar date is not the point. After a preset lands you can still edit the date and time by hand.

86,400Seconds in one countdown day

1 sInterval between redraws

8Figures reported at once

4One-click preset targets

0Seconds lost to drift

Most of this page is about a single awkward fact: two people counting down to the same moment can honestly report different numbers. The rest explains where those differences come from, which of them are real and which are display conventions, and how to make sure the number you publish is the one your audience will see.

Four steps

How to use the countdown timer

Set a target, press start, and leave it running. Nothing is uploaded and nothing is saved to a server.

Set the target date and time

Type or pick the date you are counting down to, then set the clock time beside it. The time defaults to midnight, which is almost never what people actually mean, so change it if your event has a start time.
Or use a preset

Next New Year, in 1 week, in 30 days and in 24 hours each fill the target in one click. The last three are measured from the current instant, so "in 30 days" means 720 hours from now, not the 30th of next month.
Name the event and press start

Add a label so you can tell one running timer from another, then press start. The display begins ticking once a second and keeps ticking while you scroll, switch tabs or lock the screen.
Read the totals, or pause

Below the big four fields you get total hours, total minutes, total seconds and weeks, plus a status line. Pause freezes the display without losing the target, so you can copy a figure cleanly.

Pause does not stop time

Pausing freezes the numbers on screen. It does not freeze the target. Press start again and the display jumps straight to the correct current value rather than resuming from where it was frozen.

Past dates are allowed

Set a target that has already gone and the timer counts up from it, prefixing the reading with a plus sign. That turns the same tool into a streak counter or an "it has been this long since" display.

Totals are for planning

The days and hours split is for reading. The totals are for dividing. Nineteen days is hard to budget; 456 hours splits neatly into shifts, sessions or sprints.

The display

What each number on the countdown means

Every field is the same interval seen through a different unit. Only the first four are related by carrying; the rest are independent divisions of one total.

The timer holds exactly one internal value: the remaining interval in milliseconds. Everything on screen is that one number reformatted. The four big fields come from repeated division with a remainder, which is why the hours field never exceeds 23 and the minutes and seconds fields never exceed 59. The totals come from dividing the same number by a single constant and not taking a remainder at all, which is why total hours can be 176 while the hours field reads 8.

total seconds = remaining_ms / 1,000 total minutes = remaining_ms / 60,000 total hours = remaining_ms / 3,600,000 weeks = remaining_ms / 604,800,000 days field = floor(total seconds / 86,400) hours field = floor(total seconds / 3,600) mod 24

Take a real interval and run it through both routes. At 15:20 on Thursday 24 December 2026, the gap to midnight at the start of 1 January 2027 is 636,000 seconds. Split into units that is 7 days, 8 hours, 40 minutes and 0 seconds: seven whole days uses 604,800 seconds, and the 31,200 left over is 8 hours and 40 minutes. Divided as a single total, the same 636,000 seconds is 176.667 hours, 10,600 minutes or 1.052 weeks. Nothing has been rounded away between the two views. They are two spellings of one quantity.

**Every field the countdown shows**The same interval of 636,000 seconds read nine different ways
Field	What it counts	Reading	Range it can take
Days	Whole 86,400 second blocks remaining	7	0 upward, no ceiling
Hours	Whole hours after the days are removed	8	0 to 23
Minutes	Whole minutes after days and hours	40	0 to 59
Seconds	Whole seconds after everything above	0	0 to 59
Total hours	The whole interval divided by 3,600	176.667	Any positive number
Total minutes	The whole interval divided by 60	10,600	Any positive number
Total seconds	The whole interval, unconverted	636,000	Any positive number
Weeks	The whole interval divided by 604,800	1.052	Any positive number
Status	Which side of the target you are on	Counting down	Counting down or elapsed

Add the first four back together and you get the fifth to eighth: 7 days is 604,800 seconds, 8 hours is 28,800, 40 minutes is 2,400, totalling 636,000. If you only want the unit conversion without a live clock attached, the Seconds to Minutes converter and the Minutes to Hours converter do that job on its own.

The core disagreement

Whole days remaining versus exact elapsed time

This single distinction explains most of the arguments about how many days are left until something.

There are two honest ways to answer "how many days until the event", and they routinely differ by one, sometimes by two. A countdown timer answers by measuring elapsed time and then throwing away the part that does not fill a whole day. A calendar answers by counting the boundaries between one date and another, ignoring the clock entirely. Neither is wrong. They are measuring different things.

Suppose the target is midnight at the start of Saturday 1 August 2026, and you look at the timer at 12:00 noon on Friday 31 July. The exact remaining interval is 12 hours. The countdown therefore shows 0 days, 12 hours, 0 minutes, 0 seconds, because twelve hours does not contain a whole day. Meanwhile a date calculator asked for the gap between 31 July and 1 August answers 1 day, because there is one date boundary between them. A wall planner counting inclusively, the way people count the days of a holiday, answers 2, because it counts both 31 July and 1 August. Three tools, three numbers, one moment.

Where the day count ticks over

Exact remaining time, falling continuously
Whole days shown, dropping in steps
The gap between the two readings

The two readings agree only at the exact one day boundaries and disagree everywhere else. The staircase can never sit above the line, because flooring only ever removes time. That is why a countdown spends almost the whole of its final day announcing zero days.

**One target, five moments**Counting down to midnight at the start of Saturday 1 August 2026
You look at	Exact interval left	Countdown days field	Date gap	Inclusive count
Wed 29 Jul, 08:00	2 d 16 h 00 m 00 s	2	3	4
Thu 30 Jul, 23:59	1 d 00 h 01 m 00 s	1	2	3
Fri 31 Jul, 00:00:30	0 d 23 h 59 m 30 s	0	1	2
Fri 31 Jul, 12:00	0 d 12 h 00 m 00 s	0	1	2
Fri 31 Jul, 23:59:59	0 d 00 h 00 m 01 s	0	1	2
Sat 1 Aug, 00:00:01	+0 d 00 h 00 m 01 s	+0	0	1

The date gap column is what the Date Calculator reports: the number of calendar boundaries crossed, with no reference to the clock. The inclusive count adds one because it counts both the first day and the last, the way a hotel counts nights differently from days. If you want the interval broken into years, months and days rather than a single running total, the Time Duration Calculator does that.

The practical rule is to state which convention you are using whenever the number matters to somebody else. "Three sleeps to go" is inclusive. "Three days remaining" from a countdown widget means at least 72 hours and less than 96. On a poster for an event, the safest phrasing is the exact one: not "2 days left" but "2 days and 16 hours left", or better still the date and time itself.

The 00:00 trap

Why a countdown to a date at midnight looks one day short

The single most reported problem with countdown timers is not a bug. It is the default time.

When you type only a date into a countdown and leave the time alone, almost every tool assumes 00:00:00, the very first instant of that date. That is the earliest moment the date can possibly mean. It is also, for most events, the wrong one. A wedding on 12 September does not start at one second past midnight. An exam on 12 September does not start at midnight either. But the countdown you set will end at midnight, and so it will read one day lower than the answer you were expecting for almost the entire time it runs.

Work the numbers. On Friday 24 July 2026 at 08:30 you set a countdown to Christmas Day, 25 December 2026, and leave the time at midnight. The exact interval is 153 days, 15 hours and 30 minutes, so the timer says 153 days. Ask any "how many days until Christmas" style calculator and it says 154, because there are 154 date boundaries between 24 July and 25 December. Count inclusively and you get 155. All three are defensible; only one of them appears on your screen.

24 Jul 2026 08:30 to 25 Dec 2026 00:00 = 153 d 15 h 30 m 00 s = 3,687.5 total hours = 221,250 total minutes = 13,275,000 total seconds day boundaries crossed = 154 inclusive day count = 155

Set the time, not just the date. If your event is a Christmas morning at 07:00, set the target to 07:00 and the countdown will match what people expect. If you genuinely mean "the end of the last day", set the target to 00:00 on the following date rather than 23:59 on the day itself, otherwise you quietly lose the final minute. A deadline of "the 30th" almost always means the end of the 30th, which is 00:00 on the 31st.

There is a second, subtler version of the same trap. Some events are described by a date in a document and by a time in an email, and the two never get combined. A submission portal that closes "on 30 November" may close at 23:59, at 17:00 local, or at 23:59 in a time zone on the other side of the world. Before you build a countdown around it, find the instant. A countdown is only as trustworthy as the moment it points at, and no amount of correct arithmetic rescues a target that was guessed.

The mirror image applies to birthdays and anniversaries, where people usually want the day itself rather than the first second of it. If you are counting to a birthday, the Age Calculator is a better fit, since it works in whole years, months and days and tells you the next birthday directly instead of making you reason about midnight.

Anchoring

A countdown is anchored to one zone and read everywhere

The remaining time is the same for everybody. The clock reading of the target is not.

An instant is a single point in the history of the universe. A wall clock reading is a description of that instant from one particular place. Countdown timers get into trouble because people type the second and expect the first. "The launch is at 10:00 on 15 September" is not a moment until you say where.

Once you do fix the zone, something reassuring happens: the countdown itself becomes identical everywhere. Someone in Vancouver, someone in London and someone in Tokyo looking at the same instant at the same moment all see the same digits, because they are all measuring the distance from now to the same point. What differs is only the description of the target: three different wall clock readings, and in Tokyo's case a different calendar date altogether.

One instant, three time zones, one countdown

The countdown is identical in all three places because it is a difference of instants, not a difference of clock readings. Only the description of the target changes, and in Tokyo it lands on the following calendar date, which is exactly why a broadcast trailer that says "tomorrow" can be wrong for a third of its audience.

Three practical habits follow from this. First, publish the target with its zone attached, in the form "15 September 2026, 10:00 Pacific" or, better, as a UTC instant that nobody can misread. Second, when you are the reader rather than the publisher, convert the stated time into your own zone before you trust your instincts about which day it falls on; the Time Zone Converter exists for precisely this. Third, never describe a countdown target with a relative word. "Tonight", "tomorrow" and "this weekend" are all zone dependent, and a countdown is not.

There is one more wrinkle worth naming. Some devices are set to the wrong zone, usually because they were configured while travelling and never changed back. A countdown that takes its notion of now from the device clock inherits that error, and the reading will be out by a whole number of hours in a way that looks entirely plausible. If a timer disagrees with a colleague's by exactly one, three or nine hours, suspect the zone before you suspect the arithmetic.

Clock changes

Why a countdown can appear to jump an hour

Daylight saving does not change how much time is left. It changes what the clock calls it.

Twice a year in the places that observe it, the local offset from UTC moves by an hour. In much of North America the clocks go forward on the second Sunday in March and back on the first Sunday in November. In the European Union the changes fall on the last Sunday in March and the last Sunday in October. Japan, most of Asia, most of Africa and much of South America do not shift at all, which is one reason cross border scheduling is so error prone.

For a countdown, the consequence is precise and easy to state. If the target is stored as an absolute instant, nothing whatsoever happens at a clock change: the timer keeps ticking down one second per second and never jumps. What changes is the relationship between the countdown and wall clock arithmetic. Count forward on a calendar from Friday 13 March 2027 at 20:00 to Monday 15 March at 09:00 and you will say 37 hours. The real elapsed time is 36 hours, because the hour between 02:00 and 03:00 on Sunday 14 March never happened in that zone.

13 Mar 2027 20:00 EST = 14 Mar 2027 01:00 UTC 15 Mar 2027 09:00 EDT = 15 Mar 2027 13:00 UTC elapsed = 36 h 00 m wall clock arithmetic says 37 h difference = 1 h

The autumn transition runs the other way. A span that crosses 02:00 on Sunday 1 November 2026 in eastern North America contains an extra hour, because 01:00 to 02:00 happens twice. A countdown set the previous evening will therefore appear to take longer than the calendar suggests by exactly sixty minutes.

Now the case where a countdown really does jump. If a timer stores its target as a local description rather than as an instant, and then rebuilds that instant on every tick or every page load, the offset it uses can change underneath it. Cross the transition and the rebuilt target lands an hour away from where it was, so the display leaps forward or backward by an hour between two consecutive seconds. The same thing happens when a device changes zone, for example on a phone that has just landed and picked up a new network. The fix in both cases is the same: resolve the target to a fixed instant once, at the moment it is set, and never re-derive it from a wall clock description again.

Spring forward: one hour shorter

A countdown that crosses the spring transition covers one hour less of real time than the wall calendar implies. If your event is at 09:00 on the Sunday morning of the change, everyone gets an hour less sleep and an hour less preparation than they planned for.

Autumn back: one hour longer

Crossing the autumn transition adds an hour. Overnight shifts on that date run 25 hours by the clock, which is why payroll systems treat it separately. The Time Card Calculator is the tool for that side of the problem.

Under the hood

Timer drift, tab throttling and why the maths must be redone every tick

The difference between a countdown that is right after a week and one that is minutes out comes down to a single design decision.

There are two ways to write a countdown. The naive way keeps a number of seconds in a variable, asks the browser to call a function every 1,000 milliseconds, and subtracts one each time. The correct way stores the target instant, and on every call recomputes the difference between the target and the current clock reading from scratch. The first is simpler by about two lines. It is also guaranteed to be wrong.

The reason is that a browser makes no promise to run your callback exactly 1,000 milliseconds later. It promises to run it no sooner than that. If the main thread is busy laying out a page, decoding an image or running someone else's script, the callback waits its turn and arrives late. A few milliseconds of lateness per tick is normal and invisible. But a decrementing counter treats every late arrival as if it were exactly one second, so every millisecond of lateness is silently deleted from the count. Those deletions accumulate in one direction only. Over an hour the counter runs slow; over a week it can be far enough out to be obviously wrong to anybody watching.

A timer that recomputes from the timestamp difference has no such problem, because it never remembers anything. If a tick arrives 4 milliseconds late, the difference it computes is simply 4 milliseconds smaller. If a tick is skipped entirely, the next one shows the correct value anyway. The visible symptom of lateness is at worst an occasional second that appears to be skipped on screen, which is cosmetic. The underlying number is always right.

wrong: remaining = remaining − 1 every tick, errors accumulate right: remaining = target − Date.now() every tick, errors cannot accumulate

Background tabs make the case even more strongly. Browsers deliberately slow down timers in pages you are not looking at, to save battery and CPU. The HTML specification allows a hidden page to have its timers clamped to no more than roughly one per second, and several browsers reduce that much further once a page has been hidden for a few minutes, dropping to something closer to one tick per minute. If the machine sleeps, the page may not run at all for hours. A decrementing counter comes back from that having lost every tick it missed. A recomputing countdown comes back correct on its very first redraw, and the only thing the user notices is that the numbers had frozen while they were away.

Two small refinements make the experience better still. Redrawing when the page becomes visible again means the user never sees a stale value even for a fraction of a second. And aligning the tick to the boundary of the next whole second, rather than firing a plain one second interval, keeps the seconds field from appearing to stutter or to skip a digit.

**What actually affects a countdown's accuracy**Ranked from harmless to genuinely wrong
Factor	What you see	Effect on the number	What to do
Callback jitter	Nothing, or a rare repeated second	None, if recomputed	Nothing. This is normal browser behaviour.
Background tab clamping	The display freezes, then leaps	None, if recomputed	Redraw when the page becomes visible again
Device sleep	The display stops entirely	None, if recomputed	Redraw on wake
Accumulated drift	The timer runs visibly slow	Grows without limit	Never decrement a counter. Subtract timestamps.
Leap seconds	Nothing	Up to a second over years	Ignore. Browser time treats every day as 86,400 seconds.
Wrong device clock	Everything looks fine	Off by the clock error	Turn on automatic network time
Wrong device time zone	Everything looks fine	Off by a whole number of hours	Check the zone before blaming the tool
Target given without a zone	Two people disagree	Off by up to 26 hours	Publish the target as a UTC instant
Target rebuilt from local text	A one hour jump at a clock change	Off by exactly one hour	Resolve to an instant once and store that

The three factors that actually corrupt a published countdown are the last three, and none of them are timing problems. They are all failures to pin down which moment was meant. The maximum spread of 26 hours is the full range of standard offsets in use, from UTC minus 12 to UTC plus 14.

Reference

Countdown reference tables

Exact figures for the horizons people count down over, and a note on which annual events sit still and which move.

**Common countdown horizons**How long each familiar span is in every unit the timer reports
Horizon	Days	Hours	Minutes	Seconds	Weeks
1 hour	0.0417	1	60	3,600	0.00595
1 day	1	24	1,440	86,400	0.14286
1 week	7	168	10,080	604,800	1
30 days	30	720	43,200	2,592,000	4.2857
90 days	90	2,160	129,600	7,776,000	12.857
6 months 183 d	183	4,392	263,520	15,811,200	26.143
1 year 365 d	365	8,760	525,600	31,536,000	52.143
1 leap year	366	8,784	527,040	31,622,400	52.286

The six month row uses 183 days, which is half of 366 rounded up and the figure most people mean by "six months from now". A real six calendar months is anything from 181 to 184 days depending on which months you cross, so if the calendar date matters use the Date Calculator rather than adding 183 days. The one year rows show why a countdown to an anniversary can be a day out: whether a leap day falls inside the span changes the total by 86,400 seconds.

**Annual events and how their dates behave**Which ones sit still, which drift, and what a countdown has to pin down
Event	How its date is set	Window it falls in	What the countdown must fix
New Year	Fixed calendar date	1 January, always	The zone. The new year arrives 24 or more times around the globe.
Valentine's Day	Fixed calendar date	14 February, always	The time of day you actually mean
March equinox	Astronomical instant	19 to 21 March	It is published as a UTC instant, so the local date can differ
June solstice	Astronomical instant	20 or 21 June	Same as above, and the year matters
September equinox	Astronomical instant	22 or 23 September	Same as above
December solstice	Astronomical instant	21 or 22 December	Same as above
Easter Sunday Western	Lunisolar rule	22 March to 25 April	Recompute every year. Last year's offset tells you nothing.
Chinese New Year	Chinese lunisolar calendar	21 January to 20 February	The date is set against China standard time
Ramadan	Islamic lunar calendar	Moves roughly 10 to 12 days earlier each Gregorian year	Local sighting practice can shift the start by a day
Canadian Thanksgiving	Second Monday in October	8 to 14 October	A weekday rule, not a fixed date
US Thanksgiving	Fourth Thursday in November	22 to 28 November	A weekday rule, not a fixed date
Halloween	Fixed calendar date	31 October, always	The evening, not midnight
Christmas Day	Fixed calendar date	25 December, always	Midnight or morning: pick one and say so
North American clock change	Second Sunday in March, first Sunday in November	8 to 14 March, 1 to 7 November	A countdown crossing it loses or gains an hour of wall clock time

Nothing in this table is a date you should hard code. Fixed date events still move across the week, weekday rule events move across the month, astronomical events move by hours between years, and lunar calendar events move by weeks. The only safe approach is to resolve the target for the specific year you are counting to, then store the instant.

Worked examples

Five countdowns worked through

Each one is reproducible in the timer above. The arithmetic is shown so you can check your own reasoning against it.

Counting down to New Year Preset

It is 15:20 on Thursday 24 December 2026. You press the next New Year preset, which sets the target to 1 January 2027 at 00:00:00 local.

From 24 Dec 15:20 to 31 Dec 15:20 is exactly 7 days, which is 604,800 seconds.
From 31 Dec 15:20 to 1 Jan 00:00 is 8 h 40 min, which is 31,200 seconds.
Total remaining = 604,800 + 31,200 = 636,000 seconds.
Split it: 636,000 / 86,400 = 7 whole days, remainder 31,200 s = 8 h 40 m 00 s.
As totals: 176.667 hours, 10,600 minutes, 1.052 weeks.

= 7 d 08 h 40 m 00 s remaining

Thirty days to an exam Study plan

At 09:00 on Sunday 12 April 2026 you press the in 30 days preset. The target lands on 09:00 on Tuesday 12 May 2026.

30 days is 30 × 86,400 = 2,592,000 seconds.
That is 720 total hours and 43,200 total minutes.
Remove 8 hours of sleep a night: 30 × 8 = 240 hours gone, leaving 480 waking hours.
Two hours of revision a day gives 60 hours of study inside those 480.
Sixty hours split into 45 minute blocks is 80 sessions.

= 720 h total, 480 h awake, 80 study blocks

A launch read from three cities Time zones

A launch is announced for 10:00 Pacific on Tuesday 15 September 2026. Three people open the countdown at the same instant, 09:15 UTC on 13 September.

Pacific daylight time is UTC minus 7, so the target instant is 17:00 UTC on 15 September.
From 09:15 UTC on 13 Sep to 17:00 UTC on 15 Sep is 2 days plus 7 h 45 min.
In Vancouver the target reads 10:00 on Tuesday 15 September.
In London, on UTC plus 1, it reads 18:00 on Tuesday 15 September.
In Tokyo, on UTC plus 9, it reads 02:00 on Wednesday 16 September.

= 2 d 07 h 45 m 00 s on all three screens

A countdown across a spring clock change DST

At 20:00 on Friday 13 March 2027 in eastern North America you set a target of 09:00 on Monday 15 March. Clocks jump forward at 02:00 on the Sunday.

Wall clock arithmetic: 13 Mar 20:00 to 15 Mar 20:00 is 48 h, minus 11 h = 37 h.
Convert both ends to UTC: the start is 14 Mar 01:00 UTC, the end is 15 Mar 13:00 UTC.
The real gap is 36 hours, because the hour from 02:00 to 03:00 on 14 March never occurred.
The countdown starts at 1 d 12 h 00 m and ticks down smoothly. It never jumps.
The 37 hour figure is wrong by exactly the hour that was skipped.

= 1 d 12 h 00 m 00 s, not 1 d 13 h

Counting up: a habit streak Count up

You set the target to a moment that has already gone: 19:00 on Wednesday 4 February 2026. You check it at 08:30 on Friday 24 July 2026.

4 February is day 35 of the year; 24 July is day 205. That is 170 days at the same clock time.
But you are checking at 08:30, not 19:00, so subtract 10 h 30 min.
170 days minus 10.5 hours = 169 days, 13 hours, 30 minutes.
As totals: 4,069.5 hours, 244,170 minutes, 14,650,200 seconds.
In weeks: 169.5625 / 7 = 24.223 weeks.

= +169 d 13 h 30 m 00 s elapsed

The midnight surprise Off by one

At 08:30 on Friday 24 July 2026 you set a countdown to Christmas Day and leave the time at the default midnight, so the target is 25 December 2026 at 00:00.

24 July is day 205 of 2026; 25 December is day 359. The date gap is 154 days.
You are starting at 08:30, not midnight, so 8 h 30 min of the first day is already gone.
Exact remaining = 154 days minus 8.5 hours = 153 d 15 h 30 m.
The days field therefore reads 153, one lower than the date gap of 154.
Counting inclusively, the way a paper advent chart does, gives 155.

= 153 d 15 h 30 m 00 s, and three defensible day counts

In practice

What people actually count down to

The tool is the same in every case. What changes is which of the nine figures you should be looking at.

Launches and releases

A product, a film, a game, a store opening. Anchor the instant to one zone, publish it in UTC as well, and put total hours on the internal dashboard so the team can see the runway rather than a round number of days.

Exams and assignments

Set the target to the exact closing instant of the portal, not to the date. Then read the total hours and divide them by your available study hours per day. Days remaining is far less useful than hours available.

Deadlines and filings

Tax filings, tender submissions and legal notice periods all have a hard closing instant, often stated in a specific zone. Convert it first, then count. An hour of confusion here is not recoverable.

Sport and broadcast

Kick off, first pitch, the start of a broadcast window. These are the classic case where one instant is read in dozens of zones, and where "tonight" means the following morning for a large part of the audience.

Sobriety and habit streaks

Set the target in the past and the timer counts up. Days is the figure people quote, but the count up view also gives total hours, which is often the more motivating number in the first week.

Project milestones

Sprint ends, freeze dates, go live windows. Weeks remaining is the planning unit here, and it is the one figure a days display hides: 47 days is 6.7 weeks, which reads very differently in a stand up.

In every one of these the honest version of the number includes a unit smaller than days. "Eleven days" could be anything from 11 days and one second to 11 days and 23 hours 59 minutes. If a decision depends on the difference, quote the hours too. When you need the same interval expressed as a working schedule rather than a raw span, the Hours Calculator and the Time Calculator on the home page take it from there.

Troubleshooting

Common countdown mistakes

Almost every "the countdown is wrong" report turns out to be one of these seven.

**Seven ways a countdown ends up disagreeing with reality**What goes in, what comes out, and how to correct it
Mistake	What you see	The fix
Leaving the time at midnight	The day count is one lower than expected for the entire run	Set the actual start time of the event
Using 23:59 for an end of day deadline	The countdown ends 60 seconds early	Use 00:00 on the following date instead
No time zone on the target	Two people report figures hours apart	State the zone, or publish a UTC instant
Decrementing a counter	The timer runs slow and gets worse over time	Recompute the difference on every tick
Rebuilding the target from local text	A one hour jump at a daylight saving change	Resolve the target to an instant once and keep it
Comparing a countdown with an inclusive count	An apparent off by one or off by two	Agree which convention you are both using
Trusting an unsynchronised device clock	Everything looks plausible and is uniformly wrong	Enable automatic network time on the device

Notice that only one of these seven is a programming problem. The other six are all about failing to say precisely which moment was meant, which is why the most valuable line on any countdown page is the one under the digits that spells the target out in full.

A frozen countdown in a background tab is not broken. Browsers slow timers down in hidden pages on purpose, and some suspend them completely when the device sleeps. Switch back to the tab and the display corrects itself on the first redraw, because the value is recalculated from the clock rather than remembered. If it does not correct itself, that is a genuine bug, and it means somebody built the timer by subtracting one each tick.

Definitions

Countdown glossary

The vocabulary that makes the difference between two countdowns easy to describe.

Countdown: A display of the interval between now and a future target, refreshed repeatedly so that the interval visibly shrinks. It reaches zero at the target instant.
Count up: The same display after the target has passed, showing how much time has gone by since it. Conventionally marked with a plus sign so it cannot be mistaken for time remaining.
Target instant: The single point in time being counted to, fully specified: a date, a clock time and a time zone or UTC offset. A date alone is not a target instant.
Wall clock time: The reading on a local clock, such as 10:00. It describes an instant only when you also know the place, because the same wall clock reading occurs at different instants in different zones.
UTC offset: The number of hours and minutes a local zone is ahead of or behind Coordinated Universal Time, for example plus 9 for Japan. In zones that observe daylight saving the offset changes twice a year.
Unix time: A count of seconds since 00:00:00 UTC on 1 January 1970, with no zone attached. Subtracting two Unix timestamps gives an exact interval with no calendar reasoning required.
Elapsed time: The real quantity of time that has passed between two instants, measured continuously. It is unaffected by clock changes, because a clock change alters the labels, not the passage of time.
Floor: Rounding down to the nearest whole number. A countdown floors its day, hour, minute and second fields, which is why a reading of 2 days means at least 2 days and less than 3.
Inclusive count: A day count that includes both the first day and the last, so 31 July to 1 August is two days. It is how people count holidays and advent charts, and it is one higher than the date gap.
Timer drift: The accumulating error that appears when a countdown subtracts a fixed amount on each tick instead of recomputing from the clock. Late ticks are lost permanently, so the error only ever grows.
Throttling: The deliberate slowing of timers in a page that is hidden or in a device that is saving power. It affects how often the display is redrawn, not the underlying interval.
Leap second: An occasional one second adjustment to civil time that keeps it aligned with the Earth's rotation. Browser time ignores them, treating every day as exactly 86,400 seconds.

Questions

Frequently asked questions

Direct answers to the questions people ask most about this calculation.

How does a countdown timer work?

It stores the target as a single instant, then repeatedly subtracts the current clock reading from it. The result, in milliseconds, is divided by 86,400,000 for days, by 3,600,000 for hours, by 60,000 for minutes and by 1,000 for seconds, taking remainders as it goes. Because the whole calculation is redone on every tick, nothing is remembered and no error can build up.

Why does my countdown show one day less than expected?

Almost certainly because the target time was left at midnight. A countdown to 25 December at 00:00 started at 08:30 on 24 July has 153 days and 15 hours left, so it shows 153, while a date calculator counting boundaries between the two dates says 154. Set the real start time of your event and the two figures line up with what people expect.

How many days until a date: is the last day counted?

It depends on the convention. A countdown timer counts only whole 24 hour blocks of remaining time, so it excludes both partial days. A date gap counts the boundaries between two dates. An inclusive count includes the first day and the last, which is how holidays are usually counted, and it is one higher than the date gap. State which you mean before quoting a number.

Do people in different time zones see the same countdown?

Yes, as long as the target is a fixed instant. The remaining interval is a difference between two points in time, so it is identical everywhere on Earth. What differs is the local description of the target: an instant that reads 10:00 on 15 September in Vancouver reads 02:00 on 16 September in Tokyo, a different clock time and a different calendar date.

What happens to a countdown at a daylight saving change?

If the target is stored as an instant, nothing at all happens: the timer keeps ticking one second per second. What changes is that wall clock arithmetic no longer matches. A span crossing a spring change contains one hour less real time than the calendar suggests, and one hour more across an autumn change. Timers that rebuild the target from a local description each tick can visibly jump an hour.

Why does the countdown freeze when I switch tabs?

Browsers deliberately slow timers in hidden pages to save battery, commonly clamping them to about one tick per second and sometimes to one per minute after a few minutes. If the device sleeps, the page may not run at all. The display stops updating, but the underlying value is unaffected: switch back and it corrects itself on the first redraw.

Why should a countdown never just subtract one each second?

Because a browser only promises to call your function no sooner than the interval you asked for, never exactly at it. Every late tick loses a few milliseconds, and a decrementing counter deletes those milliseconds permanently. The errors accumulate in one direction, so the timer runs steadily slow. Recomputing the difference from the clock each tick makes the error impossible.

How many seconds are in a countdown of one day, one week or one year?

One day is 86,400 seconds, one week is 604,800, thirty days is 2,592,000, ninety days is 7,776,000 and a 365 day year is 31,536,000. A leap year is 31,622,400 seconds, which is 86,400 more. These figures assume every day is exactly 24 hours, which is true except on the days a region changes its clocks.

Can I count up from a date instead of down to one?

Yes. Set the target to a moment that has already passed and the same subtraction returns a negative interval, which the timer displays as a count up with a plus sign. It is the usual way to run a sobriety counter, a habit streak, a days since last incident board or an anniversary display. All the same totals are shown.

What does the weeks figure on the countdown mean?

It is the entire remaining interval divided by 604,800 seconds, shown as a decimal. Forty-seven days remaining is 6.714 weeks. It is not the number of calendar weeks crossed and it does not care which weekday you start on. Weeks is the most useful figure for project planning, because a sprint or a schedule is usually measured in them.

Why do two countdowns to the same event disagree?

In order of likelihood: one of them was given a different time of day for the target, one of them assumed a different time zone, one is counting whole remaining days while the other counts date boundaries, or one device has an unsynchronised clock. Genuine timer inaccuracy is far down the list and almost never explains a difference of a whole day or a whole hour.

Should a deadline be set to 23:59 or 00:00?

Use 00:00 on the following day. Setting a deadline to 23:59 quietly discards the final sixty seconds of the day, which matters if anyone submits in that window. If a rule says something is due on the 30th and means the end of that day, the correct target instant is 00:00 on the 31st, with the zone stated.

Does the countdown timer store my event or send it anywhere?

No. The target, the label and every figure on screen are computed in your browser using JavaScript and never leave your device. There is no account and no server round trip, and the timer keeps ticking after you lose your connection, because it only needs the device clock to keep working.

How accurate is a browser countdown timer?

The value is as accurate as your device clock, which on a network synchronised device is typically within a fraction of a second of true time. The display can lag behind by up to a tick or more when a tab is hidden, but the number shown is always recomputed rather than carried forward, so any lag corrects itself immediately rather than accumulating.