DEV Community: CountMyDays

Building a small web app to last: the future of CountMyDays

CountMyDays — Tue, 27 Oct 2026 02:00:31 +0000

Over the last few posts I've written about the unglamorous parts of building CountMyDays: counting days without off-by-one bugs, streak counters that survive midnight and DST, and "tomorrow" vs "in 2 days" labels that respect the reader's time zone. This one is different. It's less about code and more about intent: what this little app is for, and how I want it to age.

What CountMyDays is

CountMyDays is a free web app for two simple questions:

How long until something? A wedding, a trip, an exam, a birthday.
How long since something? A new habit, a quit date, an anniversary.

You type a name and a date, and you get a countdown or a count-up with a progress bar. You can share it with one link, add it to your calendar, put it in fullscreen on a big screen, or install it to your home screen like an app. There are no ads, and you don't need an account to start. If you want your countdowns on more than one device, you can sign in with a passwordless magic link.

It's built by one developer in Iceland on React 19, Supabase and Vercel. That's the whole team.

Why "futureproof" matters for a countdown app

A countdown is a promise about the future. Someone creates one for a wedding that's 400 days away and sends the link to their family. That link has to still work, and still show the right number, on day 1 and on day 400.

That's a higher bar than it sounds. Most small web apps are judged on day one: does it look nice, is it fast? A countdown is judged on the day the event arrives. So the question I keep asking is not "what can I add?" but "what will still be true in two years?"

Here are the principles I want CountMyDays to keep, whatever else changes.

1. The core stays free and needs no account

Creating a countdown, sharing it and counting days since something should never sit behind a sign-up or a paywall. Guest mode isn't a trial; it's the product. Accounts exist for convenience (sync across devices), not as a gate.

This also keeps the app honest. If the basic thing works without me knowing who you are, there's less to go wrong and less to protect.

2. Your data is yours

A countdown is personal. You should be able to take your data with you. Today the app has a backup code and a downloadable text archive with one-click restore. I want that kind of exit door to stay a first-class feature: plain, readable formats over clever ones, and no lock-in.

3. Links that keep working

A shared link is a small contract. The direction is simple:

Share URLs should be stable. If the app changes shape, old links should still land somewhere sensible.
The number on the page has to be computed in the viewer's time zone, using calendar days, not raw milliseconds. (That's what the earlier posts in this series were really about.)
A finished countdown shouldn't just break. It should move into a "passed" state and become a memory rather than an error page.

4. Boring, standard web tech

I'd rather lean on the platform than on a pile of dependencies. A few examples from this series:

// Wording comes from the platform, in any locale the browser supports
new Intl.RelativeTimeFormat('pl', { numeric: 'auto' }).format(1, 'day');
// "jutro"

// Calendar-day maths in UTC, where every day is exactly 24 hours
const dayIndex = (y, m, d) => Date.UTC(y, m - 1, d) / 86400000;

Intl, Date.UTC, localStorage, .ics calendar files, service workers and web app manifests are standards. They'll still be here long after today's favourite library has a new major version. When the Temporal API is widely available, the date code can get even simpler without changing what users see.

The stack is deliberately small: a React front end, a Postgres database with row-level security, and static hosting with a few server routes. Small enough for one person to understand completely, which matters more than any single feature.

5. Offline and installable, as a habit of thought

A countdown is something you glance at, often on your phone, sometimes on bad Wi-Fi. Thinking "what happens with no network?" early makes the whole app better: local-first data for guests, cached assets, and sync as a bonus rather than a requirement. Progressive Web App support is part of that, and keeping it working well is ongoing work rather than a box I ticked once.

6. Accessible and calm

No ads, no pop-ups, no dark patterns. Big, readable numbers. A compact view for people with many countdowns and a spacious one for people with a single important date. Accessibility is never "done", and I'd like it to keep improving with every change rather than in one big push.

Resilience: fixing things in public

Here's my favourite part of writing on dev.to. After my first post about the app's architecture, a reader left a thoughtful comment pointing out a weakness in how the live-updating shared view used Supabase Realtime broadcasts. In short: on a public channel, the app trusted the content of broadcast messages a bit too much.

They were right. Nothing in the database could be changed or lost, but it's worth fixing properly, and that fix is underway. The idea behind it is a good general lesson, so here it is:

Treat a realtime message as a signal, not as data. When something says "this changed", go and fetch the real state from the database, where access rules apply.

channel.on('broadcast', { event: '*' }, () => {
  // Don't render the payload. Just refetch the source of truth.
  refetchSharedItem();
});

With that change, viewers still see updates live, but nothing on screen comes from an untrusted message. Tighter channel permissions are a possible next step after that.

So, a sincere thank you to that reader, and to everyone who has read, commented on or shared these posts. A small app gets more resilient when the community is generous enough to point out its weak spots.

What's next

I won't give you a roadmap with dates, because roadmaps for one-person projects are mostly fiction. What I can promise is a direction:

keep the free, no-account core
keep shared links working and numbers correct
keep the stack small and standard
keep improving offline support, accessibility and privacy
keep fixing things openly when people find problems

If any of that sounds useful, try it: create a countdown to something you're looking forward to, or a "days since" for a habit you're proud of, at countmydays.to. If you find a bug or have an idea, I'd genuinely love to hear it in the comments or on X at @countmydays_to.

Thanks for reading, and for counting along.

"Tomorrow" or "in 2 days"? A timezone-safe 'time until' label with Intl.RelativeTimeFormat

CountMyDays — Tue, 27 Oct 2026 00:27:26 +0000

Every countdown UI needs a short, friendly label: in 45 minutes, tomorrow, in 3 weeks, za 5 miesięcy. Modern JavaScript has a built-in for the wording, Intl.RelativeTimeFormat, so you no longer need a date library for it. But the API only formats a number and a unit that you pass in. Picking that number is where countdowns go wrong.

Here's the bug that pushed me to write this. It's 23:30 on 24 December in Warsaw, and the event is at midnight on the 26th, local time. Plain millisecond maths says "24.5 hours away → 1 day → tomorrow". The person reading it knows Christmas Day comes first, so for them the event is in 2 days.

This post builds a small helper that gets that right, works in any locale, and is tested in several time zones.

The easy part: wording

const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });

rtf.format(1, 'day');     // "tomorrow"
rtf.format(-1, 'day');    // "yesterday"
rtf.format(3, 'week');    // "in 3 weeks"
rtf.format(0, 'second');  // "now"

new Intl.RelativeTimeFormat('pl', { numeric: 'auto' }).format(5, 'month');
// "za 5 miesięcy"

numeric: 'auto' turns 1 day into "tomorrow" and 0 seconds into "now". With numeric: 'always' you get "in 1 day". Pluralisation, word order and grammatical case are handled for every locale the runtime supports, which is a lot of work you don't have to do.

The hard part: which number?

The usual approach is:

const days = Math.round((target - now) / 86_400_000);

This has two problems:

It counts 24-hour blocks, not calendar days. People think "how many midnights until then?", not "how many periods of 86,400,000 ms?"
It ignores whose midnight counts. The same instant is 24 December in New York and already 25 December in Auckland.

The fix is to turn both instants into calendar dates in the viewer's time zone, then subtract the dates.

Step 1: a day key in a given time zone

Intl.DateTimeFormat can tell you the calendar date of an instant in any IANA zone. The en-CA locale formats dates as YYYY-MM-DD, but I use formatToParts so the code doesn't depend on that formatting:

export function dayKey(date, timeZone) {
  const parts = new Intl.DateTimeFormat('en-CA', {
    timeZone, year: 'numeric', month: '2-digit', day: '2-digit',
  }).formatToParts(date);
  const get = (t) => parts.find((p) => p.type === t).value;
  return `${get('year')}-${get('month')}-${get('day')}`;
}

dayKey(new Date('2026-12-24T22:30:00Z'), 'Pacific/Auckland') returns "2026-12-25", because it's already Christmas morning there.

Step 2: subtract dates, not instants

Once you have two YYYY-MM-DD strings, build both as UTC midnights and subtract. UTC has no daylight saving time, so every day is exactly 86,400,000 ms and the division is exact:

export function daysBetweenKeys(fromKey, toKey) {
  const [y1, m1, d1] = fromKey.split('-').map(Number);
  const [y2, m2, d2] = toKey.split('-').map(Number);
  return Math.round(
    (Date.UTC(y2, m2 - 1, d2) - Date.UTC(y1, m1 - 1, d1)) / 86_400_000
  );
}

daysBetweenKeys('2026-03-28', '2026-03-30'); // 2, across the EU clock change
daysBetweenKeys('2026-11-01', '2026-11-02'); // 1, across the US clock change

If you did the same subtraction with local midnights (new Date(2026, 2, 30)), the 23-hour day in March would give you 1.958… days. That rounds to the right answer, but only by luck.

Step 3: put it together

Use clock time for things less than a day away ("in 45 minutes" is more useful than "today"). Use calendar days for everything else, and switch to weeks, months and years as the distance grows:

export function timeUntil(target, now = new Date(), {
  locale = undefined,
  timeZone = Intl.DateTimeFormat().resolvedOptions().timeZone,
} = {}) {
  const rtf = new Intl.RelativeTimeFormat(locale, { numeric: 'auto' });
  const diffSec = Math.round((target - now) / 1000);
  const abs = Math.abs(diffSec);

  if (abs >= 24 * 3600) {
    const days = daysBetweenKeys(dayKey(now, timeZone), dayKey(target, timeZone));
    if (Math.abs(days) >= 365) return rtf.format(Math.trunc(days / 365), 'year');
    if (Math.abs(days) >= 60)  return rtf.format(Math.trunc(days / 30), 'month');
    if (Math.abs(days) >= 14)  return rtf.format(Math.trunc(days / 7), 'week');
    return rtf.format(days, 'day');
  }
  if (abs >= 3600) return rtf.format(Math.trunc(diffSec / 3600), 'hour');
  if (abs >= 60)   return rtf.format(Math.trunc(diffSec / 60), 'minute');
  return rtf.format(diffSec, 'second');
}

Notes on the choices:

Math.trunc, not Math.round, for the coarse units. 13 days should say "in 13 days", not "in 2 weeks", and 59 days shouldn't round up to "in 2 months". Under-promising reads better on a countdown.
Months are 30 days. That's fine for a label. If you need "exactly 3 months on the calendar", compare year/month pieces instead, but no one reading "in 5 months" will check.
Negative values work for free. The same helper says "4 days ago", which is a "days since" tracker for nothing.
timeZone is a parameter. On the server (SSR, or an OG image function) there is no "viewer zone", so pass one explicitly. That might come from a cookie or from the zone the event was created in.

Testing it in three time zones

Same instant (22:30 UTC on 24 December), same targets, three runtimes:

// test.mjs
import assert from 'node:assert/strict';
import { timeUntil, daysBetweenKeys } from './until.mjs';

const tz = process.env.TZ;
const now = new Date('2026-12-24T22:30:00Z');
const o = { locale: 'en', timeZone: tz };

console.log(tz,
  timeUntil(new Date('2026-12-25T23:00:00Z'), now, o),
  timeUntil(new Date('2026-12-24T23:15:00Z'), now, o),
  timeUntil(new Date('2026-12-20T12:00:00Z'), now, o));

assert.equal(daysBetweenKeys('2026-03-28', '2026-03-30'), 2);
assert.equal(timeUntil(new Date('2026-12-24T23:15:00Z'), now, o), 'in 45 minutes');
assert.equal(timeUntil(now, now, o), 'now');

$ for z in Europe/Warsaw America/New_York Pacific/Auckland; do TZ=$z node test.mjs; done
Europe/Warsaw    in 2 days   in 45 minutes   4 days ago
America/New_York tomorrow    in 45 minutes   4 days ago
Pacific/Auckland tomorrow    in 45 minutes   4 days ago

Warsaw is the case from the start of the post. It's 23:30 on the 24th there, and the target falls at 00:00 on the 26th, so it's two midnights away. New York is still on the afternoon of the 24th and the target is the evening of the 25th, so "tomorrow" is correct. Each answer matches what a person in that city would say, and none of them comes from rounding hours.

Keeping it live

For a ticking label, don't re-render every second when the text only changes once a day. Work out when the label will next change: the next minute if it shows minutes, otherwise the viewer's next midnight. Set one setTimeout for that moment. That's cheaper and avoids layout jitter.

Wrap-up

Let Intl.RelativeTimeFormat handle the words, including "tomorrow", plurals and other languages.
Work out the number yourself, using calendar days in an explicit time zone.
Turn instants into YYYY-MM-DD with Intl.DateTimeFormat, then subtract Date.UTC values so DST never gets involved.
Test with TZ=... node in at least one zone east and one zone west of UTC.

I use this approach in Count My Days, a free, ad-free app for countdowns and "days since" trackers. If you find an edge case it misses, I'd like to hear about it in the comments.

Build a 'days since' streak counter in React with localStorage (that survives midnight, DST and bad data)

CountMyDays — Tue, 27 Oct 2026 00:00:47 +0000

"Days since I last smoked." "Days since the last production incident." "Days without sugar." A streak counter looks like the easiest widget in the world: store a start date and subtract. Then it shows 0 for two days after a clock change, crashes on the one user whose localStorage holds garbage, and stays on yesterday's number when the tab is left open overnight.

Here's the version I ended up with. It's plain JavaScript plus one React hook, with no libraries. All the logic below was run under Node 20 with TZ=Europe/Warsaw and TZ=America/New_York.

Rule 1: store calendar days, not timestamps

A streak is about days the user lived through, not milliseconds. If you store Date.now() and divide by 86,400,000, a 23-hour DST day or a trip across time zones will shift your count. So store a local day key, a plain YYYY-MM-DD string:

export function toDayKey(date = new Date()) {
  const y = date.getFullYear();
  const m = String(date.getMonth() + 1).padStart(2, "0");
  const d = String(date.getDate()).padStart(2, "0");
  return `${y}-${m}-${d}`;
}

Note the use of getFullYear/getMonth/getDate, which are local, not toISOString(). toISOString() is UTC, so in Warsaw shortly after midnight it would still say yesterday.

Rule 2: subtract day keys in UTC

To count the days between two keys, turn each into a UTC midnight. UTC has no DST, so every day there really is 86,400,000 ms long and Math.round handles the rest:

export function daysBetweenKeys(a, b) {
  const [y1, m1, d1] = a.split("-").map(Number);
  const [y2, m2, d2] = b.split("-").map(Number);
  return Math.round(
    (Date.UTC(y2, m2 - 1, d2) - Date.UTC(y1, m1 - 1, d1)) / 86400000
  );
}

export function daysSince(startKey, todayKey = toDayKey()) {
  return Math.max(0, daysBetweenKeys(startKey, todayKey));
}

Quick checks that used to bite me:

daysBetweenKeys("2026-03-28", "2026-03-30"); // 2  (EU DST weekend)
daysBetweenKeys("2026-10-24", "2026-10-26"); // 2  (EU DST ends)
daysBetweenKeys("2024-02-28", "2024-03-01"); // 2  (leap year)
daysSince("2026-11-01", "2026-10-26");       // 0  (future start never goes negative)

Math.max(0, …) matters more than it looks. Users change their device clock, and a negative streak is a bug report waiting to happen.

Rule 3: resetting should keep the record

People like seeing their best streak, and it makes a reset feel less painful. A reset is a pure function that takes the old state and returns the new one:

export function reset(state, todayKey = toDayKey()) {
  const current = daysSince(state.startKey, todayKey);
  return {
    startKey: todayKey,
    best: Math.max(state.best ?? 0, current),
    resets: (state.resets ?? 0) + 1,
  };
}

reset({ startKey: "2026-10-01", best: 10, resets: 0 }, "2026-10-26");
// { startKey: "2026-10-26", best: 25, resets: 1 }

Because todayKey is a parameter, it's trivial to test without mocking Date.

Rule 4: treat localStorage as hostile

localStorage can be missing (some private modes), full, or hold an old format from last year's version of your app. Wrap it so that the worst case is "start fresh", never a white screen:

export function load(storage, key, todayKey = toDayKey()) {
  try {
    const raw = storage.getItem(key);
    if (!raw) return { startKey: todayKey, best: 0, resets: 0 };
    const s = JSON.parse(raw);
    if (!/^\d{4}-\d{2}-\d{2}$/.test(s.startKey)) throw new Error("bad data");
    return { best: 0, resets: 0, ...s };
  } catch {
    return { startKey: todayKey, best: 0, resets: 0 };
  }
}

export function save(storage, key, state) {
  try {
    storage.setItem(key, JSON.stringify(state));
  } catch {
    // quota exceeded or storage disabled: keep working in memory
  }
}

Passing storage in, instead of touching window.localStorage directly, lets you test it in Node with a five-line fake:

const mem = new Map();
const storage = {
  getItem: (k) => mem.get(k) ?? null,
  setItem: (k, v) => mem.set(k, v),
};
mem.set("streak", "{oops");
load(storage, "streak", "2026-10-27").startKey; // "2026-10-27", no crash

If you ever change the shape, add a version field now. Future you will thank you.

Rule 5: tick over at local midnight

The classic bug: the tab stays open overnight and still shows yesterday's number. You don't need a one-second interval. Schedule a single timeout for the next local midnight, and also refresh when the tab becomes visible again, because timers get throttled in background tabs and laptops go to sleep.

import { useEffect, useState, useCallback } from "react";
import { toDayKey, daysSince, reset, load, save } from "./streak";

function msUntilNextMidnight(now = new Date()) {
  const next = new Date(now);
  next.setHours(24, 0, 0, 0); // local midnight, DST-aware
  return next - now;
}

function useToday() {
  const [today, setToday] = useState(toDayKey);
  useEffect(() => {
    let timer;
    const refresh = () => setToday(toDayKey());
    const schedule = () => {
      timer = setTimeout(() => { refresh(); schedule(); }, msUntilNextMidnight() + 1000);
    };
    schedule();
    document.addEventListener("visibilitychange", refresh);
    return () => {
      clearTimeout(timer);
      document.removeEventListener("visibilitychange", refresh);
    };
  }, []);
  return today;
}

export function useStreak(key = "streak") {
  const today = useToday();
  const [state, setState] = useState(() =>
    typeof window === "undefined"
      ? { startKey: today, best: 0, resets: 0 }
      : load(window.localStorage, key, today)
  );

  useEffect(() => {
    save(window.localStorage, key, state);
  }, [key, state]);

  // keep several tabs in sync
  useEffect(() => {
    const onStorage = (e) => {
      if (e.key === key) setState(load(window.localStorage, key, toDayKey()));
    };
    window.addEventListener("storage", onStorage);
    return () => window.removeEventListener("storage", onStorage);
  }, [key]);

  const doReset = useCallback(() => setState((s) => reset(s, toDayKey())), []);

  return {
    days: daysSince(state.startKey, today),
    best: Math.max(state.best, daysSince(state.startKey, today)),
    resets: state.resets,
    reset: doReset,
  };
}

setHours(24, 0, 0, 0) asks the engine for "the next local midnight", so DST is handled for you. The extra second avoids landing at 23:59:59.999 because of timer jitter.

The component

export function StreakCard({ label }) {
  const { days, best, reset } = useStreak(`streak:${label}`);
  return (
    <section aria-live="polite">
      <h2>{label}</h2>
      <p style={{ fontSize: "3rem", margin: 0 }}>{days}</p>
      <p>{days === 1 ? "day" : "days"} · best: {best}</p>
      <button onClick={() => confirm("Reset this streak?") && reset()}>
        Reset
      </button>
    </section>
  );
}

Two small UX details: aria-live so screen readers announce the new count at midnight, and a confirm step, because an accidental tap that wipes a 200-day streak is the fastest way to lose a user.

Server rendering note

If you render on the server (Next.js and friends), the server doesn't know the user's time zone or their localStorage. Render a neutral placeholder and fill in the number after hydration, or you'll get hydration mismatch warnings around midnight. The typeof window guard above covers the initial state.

Recap

Store local day keys (YYYY-MM-DD), not timestamps.
Subtract them in UTC, and clamp at zero.
Make reset a pure function that keeps the best streak.
Treat localStorage as unreliable: validate, catch and fall back.
Re-render at local midnight and on visibilitychange.

That's about 100 lines for a counter that behaves correctly on DST weekends, on leap days, and in tabs left open for a week.

If you'd rather not build it yourself, I made this into a free app with countdowns and "days since" trackers, no ads and no sign-up: CountMyDays.

Counting days between two dates in JavaScript without off-by-one bugs

CountMyDays — Mon, 26 Oct 2026 23:48:28 +0000

"How many days until 24 December?" sounds like a one-liner. In JavaScript it's a small trap with three jaws: time zones, daylight saving time and the way Date parses strings. I ran into all three while building a countdown app, so here's what goes wrong and the small set of helpers I ended up trusting.

All snippets below were run in Node 20. The Temporal one uses the @js-temporal/polyfill package.

Pitfall 1: a day is not always 86,400,000 ms

The classic approach:

const a = new Date(2026, 2, 28); // 28 March 2026, local midnight
const b = new Date(2026, 2, 30); // 30 March 2026, local midnight
console.log((b - a) / 86400000);

In a European time zone (I ran it with TZ=Europe/Warsaw) this prints:

1.9583333333333333

Clocks went forward on 29 March, so that local "day" was only 23 hours long. Depending on whether you then use Math.floor, Math.ceil or nothing, you get 1, 2 or a fraction. In autumn you get the opposite: a 25-hour day and 1.04-ish.

The underlying problem: you're measuring elapsed time, but the question was about calendar days. Those are different things.

Pitfall 2: `new Date('2026-03-29')` is UTC, but `new Date('2026-03-29T00:00')` is local

console.log(new Date('2026-03-29').toISOString());      // 2026-03-29T00:00:00.000Z
console.log(new Date('2026-03-29T00:00').getHours());   // 0 (local midnight)

A date-only ISO string is parsed as UTC midnight. Add a time and it becomes local. So for a user in New York, new Date('2026-03-29').getDate() returns 28, because UTC midnight is still the previous evening there. If you mix the two forms in one app (say, one from an <input type="date"> value and one from a database timestamp), you'll get off-by-one errors that only show up for some users.

Fix: compare calendar days, not milliseconds

The trick is to throw away the time of day and the time zone before subtracting. Take the year, month and day the user sees, and build a UTC midnight from them. UTC has no DST, so every day in it is exactly 86,400,000 ms.

function toUTCDay(d) {
  return Date.UTC(d.getFullYear(), d.getMonth(), d.getDate());
}

function daysBetween(start, end) {
  return Math.round((toUTCDay(end) - toUTCDay(start)) / 86400000);
}

// 23:30 on the 28th to 00:05 on the 30th, across the DST change:
console.log(daysBetween(new Date(2026, 2, 28, 23, 30), new Date(2026, 2, 30, 0, 5))); // 2

Math.round is a belt-and-braces guard; with both sides at UTC midnight the division is already an integer.

If your dates arrive as YYYY-MM-DD strings (date inputs, a date column in Postgres), don't hand them to new Date() at all. Parse the parts yourself:

function parseDateOnly(str) {
  const [y, m, d] = str.split('-').map(Number);
  return Date.UTC(y, m - 1, d);
}

const diff = (parseDateOnly('2026-12-24') - parseDateOnly('2026-10-27')) / 86400000;
console.log(diff); // 58

Treat date-only values as labels for a calendar day, not as instants. That one mental rule removes most of these bugs.

"Today" depends on where you are

Countdowns need "today", and "today" is a time-zone question. At 23:30 UTC on 26 October it's already the 27th in Tokyo. Intl.DateTimeFormat can tell you the calendar date in any zone without a library. The en-CA locale happens to format as YYYY-MM-DD, which plugs straight into parseDateOnly:

function todayIn(timeZone, now = new Date()) {
  return new Intl.DateTimeFormat('en-CA', {
    timeZone, year: 'numeric', month: '2-digit', day: '2-digit',
  }).format(now);
}

const now = new Date(Date.UTC(2026, 9, 26, 23, 30));
console.log(todayIn('Atlantic/Reykjavik', now));  // 2026-10-26
console.log(todayIn('Asia/Tokyo', now));          // 2026-10-27
console.log(todayIn('America/Los_Angeles', now)); // 2026-10-26

For anything shown to a user, compute "today" in their zone (the default when you omit timeZone), not the server's. A server-rendered "3 days left" from a server in UTC can easily be wrong for half your users.

"Days since": decide whether day one is 0 or 1

Counting up has its own off-by-one, and it isn't a bug in the code, it's a product decision. If I start a habit today, is that "0 days" or "day 1"?

function daysSince(startStr, todayStr) {
  return (parseDateOnly(todayStr) - parseDateOnly(startStr)) / 86400000;
}

console.log(daysSince('2026-10-26', '2026-10-26')); // 0
console.log(daysSince('2026-10-26', '2026-10-27')); // 1

"Days since" (elapsed) naturally starts at 0. "Day N of a streak" starts at 1, so it's daysSince(...) + 1. Pick one, name the function after it, and don't let the + 1 drift around the codebase.

For display, Intl.RelativeTimeFormat handles the wording and pluralisation in any language:

const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
console.log(rtf.format(-1, 'day')); // yesterday
console.log(rtf.format(58, 'day')); // in 58 days

Temporal: the real fix (when you can use it)

The Temporal API was designed for exactly this. It has a PlainDate type, a calendar date with no time and no zone, so the whole class of bugs above can't happen:

import { Temporal } from '@js-temporal/polyfill';

const start = Temporal.PlainDate.from('2026-10-27');
const end = Temporal.PlainDate.from('2026-12-24');
console.log(start.until(end, { largestUnit: 'day' }).days); // 58

const today = Temporal.Now.plainDateISO('Atlantic/Reykjavik'); // today in that zone

Native support is still arriving across browsers and runtimes, so check support for your targets or ship the polyfill. The toUTCDay approach above is a good bridge until then, and it maps cleanly onto PlainDate later.

Live countdowns are a different problem

Everything above is about whole days. A ticking "2d 4h 13m 09s" timer is about elapsed time, and there the millisecond difference is the right tool, as long as you always derive it from the clock instead of accumulating ticks. setInterval(tick, 1000) drifts and fires slightly late. Recomputing from Date.now() on each frame doesn't.

How CountMyDays handles it

CountMyDays is my side project for countdowns and "days since" trackers, built with React 19, Supabase and Vercel as an installable web app. A few of the choices in it come straight from the lessons above:

The timer is pure date math. Every frame it computes the difference from Date.now(), and a requestAnimationFrame loop only calls setState when the visible second changes. Because the value is always derived from the clock, there's no accumulated error. Background tabs pause rAF, so the hook switches to a 500 ms interval on visibilitychange and back again when the tab returns.
One function, four cases. When a countdown passes zero it flips to counting the time elapsed since the date, and a "days since" tracker with a future start date counts down until it starts. Keeping that in a single calculation function means the edge cases live in one place.
Normalise dates on the way in. Older data had targetDate, newer data target_date. The code accepts both and converts to ISO strings once, instead of letting two formats leak into the date math.

Cheat sheet

Days between dates: normalise both to UTC midnight (Date.UTC(y, m, d)), then divide.
Never pass YYYY-MM-DD to new Date() and then read local fields. Parse it yourself.
Compute "today" in the user's zone (Intl.DateTimeFormat with timeZone).
Decide whether "days since" starts at 0 or 1, and encode it in the function name.
Live timers: derive from the clock every frame, never count ticks.
Use Temporal.PlainDate where you can.

If you want to see these in practice, CountMyDays is free with no ads and no sign-up: countmydays.to. I'd love to hear about any date bugs that have bitten you in the comments.

How I built a countdown & days-since tracker with React 19, Supabase and Vercel

CountMyDays — Mon, 26 Oct 2026 19:10:54 +0000

I wanted a place to count down to things – a trip, a birthday, a deadline – and to count up from things, like the day I started a habit. Most countdown sites I tried were full of ads or wanted an account before I could type a date. So I built my own: CountMyDays. It's a solo side project, and this post is about how it's put together and a few things that bit me along the way.

The stack

React 19 + Vite + TypeScript for the frontend
Supabase for Postgres, magic-link auth and Realtime
Vercel for hosting
Tailwind for styling, and a service worker so it installs as a PWA and works offline

Nothing exotic. The interesting parts are in how data moves between "guest" and "signed in", and in how the timer stays accurate.

Guest first, account later

I didn't want a sign-up wall. When you open the app you can create countdowns immediately, and they're stored in localStorage under a single key:

const STORAGE_KEY_LOCAL_COUNTDOWNS = 'countmydays_local_milestones';

Pins and favourites live in their own small keys (countmydays_pinned_ids, countmydays_favorite_ids) so they're cheap to toggle.

Sign-in is passwordless: Supabase sends a magic link. The tricky bit is what happens to the guest data afterwards. I didn't want people to lose the countdowns they made before signing in, so after login the app maps the local items into rows for the countdowns table and inserts them in one go:

const rows = local.map((m) => ({
  user_id: session.user.id,
  title: (m.title || 'Untitled Milestone').trim().slice(0, 120),
  target_date: new Date(m.target_date || m.targetDate || Date.now()).toISOString(),
  type: m.type || 'countdown',
  is_pinned: Boolean(m.is_pinned ?? m.isPinned),
  is_favorite: Boolean(m.is_favorite ?? m.isFavorite),
  show_progress_bar: m.show_progress_bar !== false && m.showProgressBar !== false,
  start_date: m.start_date || m.startDate || null,
  created_at: m.created_at || m.createdAt || new Date().toISOString(),
}));

let { data, error } = await supabase.from('countdowns').insert(rows).select();

A few lessons from this:

Normalize on the way in. Early versions stored camelCase (targetDate), later ones snake_case (target_date). The migration accepts both rather than pretending old data doesn't exist.
Have a fallback for schema drift. If the insert fails (for example an older database without the pin/favourite columns), it retries without those fields instead of failing the whole migration.
Only clear local data after the insert succeeds. The localStorage keys are removed after Supabase confirms the rows, never before.

Security-wise, the browser only ever has the publishable key; what a user can read and write is enforced by Row Level Security policies in Postgres, so each row is tied to user_id.

A timer that doesn't drift

The obvious approach is setInterval(tick, 1000). The problem is that intervals drift and can fire just after a second boundary, so the display looks laggy next to a real clock.

Instead the timer is pure date math – every frame it computes the difference from Date.now() – and a requestAnimationFrame loop only calls setState when the visible second actually changes:

const tick = () => {
  const current = calculateLiveTime(targetDate, type);
  if (current.seconds !== lastSecondRef.current) {
    lastSecondRef.current = current.seconds;
    setTime(current);
  }
  animId = requestAnimationFrame(tick);
};

Because the value is always derived from the clock, there's no accumulated error. Browsers pause requestAnimationFrame in background tabs, so the hook listens for visibilitychange and switches to a 500 ms interval while hidden, then back to rAF when the tab returns.

One small product decision lives in calculateLiveTime: when a countdown passes zero, it doesn't just show "0". It flips to counting the elapsed time since the date. And "days since" trackers with a future start date count down until they start. Same function, four cases.

Live shared links with Supabase Realtime

Every countdown can be shared via a public link. I wanted the shared page to update the moment the owner edits it – handy if you put a countdown on a TV and change the title from your phone.

The shared view subscribes to one channel per countdown and listens to two things: Postgres changes on that single row, and broadcast events.

channel = supabase
  .channel(`live_milestone_${id}`)
  .on('broadcast', { event: 'milestone:live_stream' }, ({ payload }) => {
    /* apply title / date changes instantly */
  })
  .on('broadcast', { event: 'milestone:deleted' }, () => onNavigate('404'))
  .on('postgres_changes',
    { event: '*', schema: 'public', table: 'countdowns', filter: `id=eq.${id}` },
    (payload) => { /* source of truth from the database */ })
  .subscribe();

Why both? postgres_changes is the reliable source of truth, but it only fires after the write lands. Broadcast lets the editor push changes straight to viewers with less delay. If the owner un-shares the countdown (is_shared === false), viewers are sent to a 404 straight away.

On the sending side, I keep a small pool of joined channels in a Map so repeated broadcasts don't re-subscribe each time. Channels are removed when the view unmounts.

The Vercel SPA rewrite gotcha

The app is a single-page app, so every route needs to serve the same HTML. The standard Vercel config is a rewrite that sends everything except the API to index.html:

{
  "rewrites": [
    { "source": "/((?!api/).*)", "destination": "/index.html" }
  ]
}

That works – until you turn on cleanUrls. While experimenting with adding static pages, I enabled cleanUrls: true, and suddenly existing routes started returning 404. With cleanUrls, Vercel serves /index.html at / and treats .html paths differently, so a rewrite to /index.html no longer resolves the way you'd expect. The fix was to point the rewrite destination at / instead:

{ "source": "/((?!api/).*)", "destination": "/" }

The related SEO lesson: a catch-all rewrite also means every unknown URL returns 200 with your app shell – a "soft 404" for search engines. I also had to add real robots.txt and sitemap.xml files, because before that, those URLs simply returned the app's HTML.

What I'd do differently

Decide on one data shape on day one. Supporting both camelCase and snake_case cost more code than it should.
Think about crawlers early. A client-rendered SPA shows an empty <body> to anything that doesn't run JavaScript. Pre-rendering key pages is next on my list.
Keep the guest path. Letting people try the app without an account was the best decision I made.

Try it

If you count down to anything – or count days since something – it's free and has no ads: countmydays.to. Feedback on the code approach is very welcome in the comments.