Counting down to a date across daylight saving

The countdown has two modes. Duration mode counts a length of time; date-and-time mode counts to a fixed instant. This guide is about the second, because it is the one that touches the calendar, and the calendar is where the clocks change.

The setting the tool keeps for a date-and-time countdown is not an instant. It is the plain string the datetime-local input produces — for the example running through this guide, 2026-12-25T09:00 — and the engine turns that string into the instant the countdown should reach zero every time it needs one, by reading it in this device's own time zone. The engine's header puts the rule in one sentence: target mode parses the string in the viewer's own zone, so a countdown that spans a daylight-saving change is short or long by exactly one hour, which is what a wall clock actually does.

The label the countdown stage shows above the digits is the engine's own description of that instant — its weekday, date and time — rendered in your browser's locale and zone, so the wording may differ from device to device while the wall-clock time stays the same. Read as New York's wall clock would read it, using only the offsets Intl reports for America/New_York and the en-US formatters this site's clocks use, the example target is Friday, December 25, 2026, 9:00 AM; that is the form the tables on this page give it. The remaining time is then one subtraction — the target instant minus now — and the readout is that number formatted as hours, minutes and seconds.

The table fixes the target at 2026-12-25T09:00 as New York's wall clock would show it and evaluates the engine at five moments relative to it; every row is a difference from the target, so the zone chosen for the instant changes no digit. The second column is what remainingToTarget returns; the third is what the stage shows. Seconds round up on the display, so one millisecond before the target still reads a full second, and the countdown page clamps the readout at zero once the target has passed: the engine's remaining time goes negative, but the stage replaces its label with “Time is up” and holds the digits rather than counting into overtime. The words column rounds to the nearest second, which is why one millisecond before the target reads 0 seconds in words but 00:00:01 on the clock.

The readout always carries an hours field in this tool, which is why a short remainder reads 00:01:30 rather than a bare minutes-and-seconds pair. The tab title carries the same readout, followed by the word Countdown, while the count runs, so a backgrounded countdown is still readable from the tab strip.

A countdown to doors opening is a promise about a wall clock. The doors open when the clock on the wall says the time you wrote, not after a fixed number of seconds you worked out in advance. If the clocks change between now and then, the number of real seconds until that wall-clock moment changes with them, and a countdown that ignored the change would reach zero an hour early or an hour late in the room.

That is why the engine reads the target with the platform's own zone rules rather than treating the written hours as a bare quantity. Its parser builds the instant from the year, month, day, hour and minute you typed, and the platform applies the zone rules using the time-zone data shipped with your browser, daylight saving included, as the about page puts it. The remaining time is then the true gap to that instant, however many clock changes lie between.

The honest consequence, stated on the tool page itself, is that a date-and-time countdown can be an hour shorter or longer than the calendar suggests. The next section computes that difference rather than asserting it.

The table takes three spans, each written as a pair of datetime-local strings. The first column is the span the written digits suggest if no zone is applied at all. The second evaluates the same two strings in New York's zone, America/New_York, using only the offsets Intl reports for that zone at those instants. The engine's own parser is not run for this table, because it reads strings in the zone of whatever machine runs it; the engine's test file is the authority instead, and the paragraph after the table says what it asserts.

In New York the March night is 1 hour shorter than written and the November night is 1 hour longer than written, while the June day is the same as the written span. The offsets explain the arithmetic. Intl reports the start of the March span at UTC−5 and its end at UTC−4; the November span runs from UTC−4 to UTC−5; the June day stays at UTC−4 throughout. When the offset moves between the two ends, the real span differs from the written one by the size of that move, and in neither direction is anything lost or invented: the clocks in the room did the same.

As a check that the instants really are the written wall-clock times in that zone, formatting them back through Intl gives Saturday, March 7, 2026, 20:00:00 and Sunday, March 8, 2026, 08:00:00 for the March span, and Saturday, October 31, 2026, 20:00:00 and Sunday, November 1, 2026, 08:00:00 for the November one.

The engine's test file runs durationBetweenLocal on these same three spans with its zone pinned to America/New_York, and asserts exactly the figures in the second column: 11 hours for the March night, 13 hours for the November night and 24 hours for the June day. In your browser the same arithmetic runs in your zone, and that is the whole point of the design: the same two strings give the answer for whatever zone the device is in. The tool does not ask which zone you meant, because a wall-clock target only makes sense in the zone of the wall.

The hour is easiest to see by following a single countdown through the night. Fix the target at the end of the March span, 2026-03-08T08:00 as New York's wall clock would show it, and evaluate the remaining time at four wall-clock moments, each converted to an instant with the offsets Intl reports for America/New_York. The third column formats the instant back through Intl as the check that it is the wall-clock time written.

Between the wall-clock times 01:59:00 and 03:00:00 the clock in the room advanced by 1 hour 1 minute, because the offset moved from UTC−5 to UTC−4 between those two rows. Yet 1 minute of real time passed, and the readout moved by exactly that, from 05:01:00 to 05:00:00. Nothing lurches at the change, because the countdown was never counting wall-clock minutes: every tick subtracts now from a fixed instant, and now does not care what the wall says.

The whole of the hour is already in the first row. The evening before, with the change still ahead, the readout shows 11:00:00 rather than the 12 hours the written digits suggest. A date-and-time countdown does not lose an hour when the clocks change; it never had that hour, because the instant it counts to was fixed by the wall clock from the start.

On the night the clocks spring forward, a stretch of wall-clock time is skipped, and a target typed inside it names a moment that never arrives. The engine's parser leaves the resolution to the platform: a time that does not exist because the clocks sprang forward normalises to the following instant, matching the platform's own resolution.

The engine's test file exercises this with 2026-03-08T02:30 against 2026-03-08T03:30 in New York's zone, with the zone pinned to America/New_York, and asserts that the two parse to the same instant. The offsets Intl reports for that zone show why. In the last minute before the gap, 01:59:00 on the wall, the offset is UTC−5; reading the skipped digits with that offset gives an instant Intl formats back as 03:30:00, which is the same instant that 2026-03-08T03:30 names in that zone — the carrying forward the header describes. A device in a zone with no gap there simply counts to the time as written. The header speaks only to a time the clocks skip; it says nothing about the November move, and nor does this guide.

Calendar overflow is treated differently: it is rejected, not rolled. A day the month does not have, such as the thirty-first of February, or an hour of twenty-five, produce no instant at all — 2026-02-31T00:00 parses to nothing and 2026-06-15T25:00 to nothing — and the settings normaliser then keeps the countdown in duration mode rather than counting to a date that cannot be read. Asking for target mode with the overflowing date above yields mode duration. The parser is more forgiving about form than about validity: an optional seconds field is honoured, so 2026-06-15T13:45:30 lands 30 seconds after 2026-06-15T13:45, and a space in place of the T reads the same instant. A span with one malformed end is refused the same way: durationBetweenLocal given nope and 2026-06-15T08:00 returns nothing, because a span needs both of its ends to be read.

Duration mode is the other half of the tool, and it is immune to all of the above. The default is 00:05:00 — 5 minutes — and it is a starting point you can change, not a limit. When you press start, the engine records the instant the count should end as an epoch: the start instant plus the duration. Epoch milliseconds carry no zone, so a duration that happens to run across a clock change is neither an hour short nor an hour long; only a wall-clock target is measured against the wall clock.

The walk-through below starts the default duration at a fixed instant — Monday, June 15, 2026 at 12:00:00 UTC, which is epoch 1781524800000, a constant in this page's source — and evaluates the engine at fixed moments after it. The run's end is recorded 5 minutes after the start; one minute in, the readout is 00:04:00. Pausing 2 minutes in stores a balance of 3 minutes and nothing else — no end instant, because none is known yet. Resuming 8 minutes later re-anchors that balance to the new instant, so the end now falls 13 minutes after the original start: the whole 8 minutes of the pause has moved it, and not a millisecond more.

The display rounds seconds up, so a freshly set default reads 00:05:00, one millisecond into the run it still reads 00:05:00, and only a full second in does it read 00:04:59. A countdown that appears to hold its first second slightly long is behaving correctly: the digits change when a whole second has elapsed, not when the first millisecond has.

Duration settings are normalised before they run, and the tool page sets out the bounds with its own worked figures; here, asking for 1000 hours yields 99:00:00, which is 99 hours, the ceiling; a duration of nothing at all is raised to 1 second, the floor; and the message under the clock is cut at 120 characters, in the field and in a shared link alike. What matters for this guide is that the ceiling belongs to duration mode alone. A date-and-time target has no equivalent, because its only requirement is a string the parser can read.

Copy preset link writes the settings into the query string. For the example target with the message “Doors open” the engine produces ?at=2026-12-25T09%3A00&msg=Doors+open, and reading that query back gives target 2026-12-25T09:00, mode target and the message “Doors open”. The link carries the wall-clock string, not the instant, which follows from what the tool stores — and it has a consequence worth knowing before you send one.

Whoever opens the link counts to 2026-12-25T09:00 on their own wall clock. Evaluating that string with the offsets Intl reports gives 09:00:00 at UTC−5 in New York and 09:00:00 at UTC in London: the same digits, but instants 5 hours apart. When London's countdown reaches zero, a clock in New York reads 04:00:00. For a room, that is right — the doors open at 9:00 AM by the clock in the room, wherever the room is. For a single moment shared across zones, say a broadcast, each recipient should type the target as it falls on their own clock, which the converter can tell them.

Two details of how the countdown page reads a link, as that page is written. A link whose target has already passed opens straight onto “Time is up”, because the remaining time is already at or below zero. And precedence between a link and what this browser already holds turns on one test, applied to the saved run record alone, whatever mode the page was in: if that record is still running — its status is running and its end instant has not yet passed — the saved state takes precedence over the link; otherwise the shared settings win. A date-and-time countdown starts no run record of its own, because its target is re-read from the saved string, so a date-and-time countdown whose run record is idle steps aside for a shared link, as a paused or finished duration does. Switching mode does not touch the record, which is why the test is on the record and not on what the page was showing; the only thing that beats a link is, precisely, a saved duration run still running.

Running state is saved to this browser's storage as epochs, never as seconds left. The envelope the countdown page writes for the duration walk-through above, saved 1 minute 30 seconds after its start — at epoch 1781524890000 — is {"v":1,"savedAt":1781524890000,"state":{"settings":{"mode":"duration","durationMs":300000,"targetValue":"","message":""},"run":{"status":"running","endsAt":1781525100000},"muted":false}}: a version, the instant of saving and the state that page keeps, in the shape it is written to use — the settings the run started from, the run with its end instant, and whether the chime is muted. On reload the remaining time is recomputed from that end instant against the clock, so a reload costs nothing. Envelopes age out after 12 hours, a rule the tool page walks through with its own example run. What matters here is the date-and-time case: such a countdown has no end instant to save. Its settings carry the target string, and that string is parsed afresh in whatever zone the device is in when the page comes back.

Where the mechanism stops is the browser's own edge, and the following is described, not simulated. The countdown lives in this page: the tab has to stay open for the chime to sound, and phones and laptops that fall asleep can delay or suppress the tone. The arithmetic is unaffected — the display is correct for whatever instant a tick runs at, because every tick subtracts now from the stored target rather than adding to a count — so a device that was asleep shows the right state at its next tick. Where the browser supports a screen wake lock, the tool holds one while the count runs and the tab is visible; where it does not, the page says so, and the device's own screen timeout is the thing to raise.

• “The countdown is an hour out.” If the clocks change between now and the target, a date-and-time countdown is an hour shorter or longer than the written span, and the room's clock will do the same. Compare it with the wall clock, not with the calendar arithmetic.
• “My colleague's link shows a different time.” The link carries the wall-clock string, so each device counts to that time on its own clock. For a shared instant, each person types the target as it falls where they are.
• “It sat on 00:05:00 for a whole second.” Seconds round up. The digits change when a full second has elapsed, which is what makes a fresh timer read its set length rather than one second less.
• “It stopped at zero instead of showing how late we are.” The countdown holds at zero and says “Time is up”. Overtime counting is the speech timer's job, and it shows the amount over counting upward with a plus sign.
• “I typed a time on the change-over night and it moved.” A time the clocks skip is carried forward by the size of the gap, 1 hour, so the typed digits land that much later on the wall clock: the engine's test pins 2026-03-08T02:30 to the same instant as 2026-03-08T03:30. That is the platform's own resolution, not a guess by the tool.