Functional Weave
Code in TypeScript

dates.add-days

Shift an ISO date by a whole number of days, forwards or backwards, with exact calendar arithmetic.

1.0.0 · published 2026-10-03 by charlie · Anterra

Pinned by 28 tests, run in TypeScript, Python and Rust.

What it does

This is the civil-date kernel for the whole dates family: days-from-civil and civil-from-days, converting a calendar date to a day number counted from 1970-01-01 and back. Every other dates capability imports it rather than re-deriving the arithmetic.

No date library is used in any of the three languages, and that is a decision, not an omission. JavaScript's Date parses "2026-09-16" as UTC midnight but new Date(2026, 8, 16) as local midnight, so the same calendar day can come back a day out depending on the machine's timezone, and setMonth rolls 31 January into 3 March. Python's datetime and Rust's chrono are each correct on their own but would mean three different libraries answering the same question, which is exactly what the parity vectors exist to rule out.

For example

  • addDays(2026-09-16, 1) → 2026-09-17 one day forward mid-month
  • addDays(2026-09-16, 0) → 2026-09-16 zero days is the same date back
  • addDays(2024-02-28, 1) → 2024-02-29 2024 is a leap year so 28 February is followed by the 29th

The function

The same function in TypeScript, Python and Rust, pinned by the same tests. Pick your language; the choice follows you around the registry.

export function addDays(iso: string, days: number): string
isodateISO date, YYYY-MM-DD
daysintwhole days to add; negative moves backwards
returnsdate

The type it declares, generated into your project

/** A calendar date as numbers, for the arithmetic other date capabilities do. */
export interface CivilDate {
  readonly year: number;
  /** 1 to 12 */
  readonly month: number;
  /** 1 to 31 */
  readonly day: number;
}

Your code names it in one line, in the file that uses it

import { addDays } from "#fune/dates.add-days@^1";
impl/typescript.ts · 140 lines · open · raw
/**
 * Civil-date arithmetic on ISO "YYYY-MM-DD" strings.
 *
 * This deliberately does not use JavaScript's `Date`. `new Date("2026-09-16")`
 * parses as UTC midnight while `new Date(2026, 8, 16)` parses as local
 * midnight, so the same calendar day can come back a day earlier or later
 * depending on the machine's timezone; and `setMonth` silently rolls 31
 * January into 3 March. Both are exactly the class of bug this registry exists
 * to eliminate, and both disappear once the arithmetic is done on integers.
 *
 * The kernel is the days-from-civil / civil-from-days pair: a calendar date is
 * converted to a day number counted from 1970-01-01, shifted, and converted
 * back. Every division below has non-negative operands inside the supported
 * year range, so truncating division (Rust), floor division (Python) and
 * Math.floor (TypeScript) all agree, which is what lets the three
 * implementations be transliterations of one another.
 */

import { type CivilDate } from "./dates_add_days_types.ts";

/** 0001-01-01 and 9999-12-31 as epoch days: the range a 4-digit ISO year can express. */
const MIN_EPOCH_DAY = -719162;
const MAX_EPOCH_DAY = 2932896;

const MONTH_LENGTHS = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31];

/**
 * The Gregorian rule in full: every 4th year, except every 100th, except every
 * 400th. 1900 was not a leap year and 2000 was, and code that only tests
 * `year % 4` gets one of those two wrong.
 */
export function isLeapYear(year: number): boolean {
  return year % 4 === 0 && (year % 100 !== 0 || year % 400 === 0);
}

export function daysInMonth(year: number, month: number): number {
  if (month < 1 || month > 12) {
    throw new RangeError(`month must be 1-12, received ${month}`);
  }
  if (month === 2 && isLeapYear(year)) return 29;
  return MONTH_LENGTHS[month - 1];
}

function isDigits(value: string, from: number, to: number): boolean {
  for (let i = from; i < to; i++) {
    const code = value.charCodeAt(i);
    if (code < 48 || code > 57) return false;
  }
  return true;
}

/**
 * Parse and validate, rejecting both shapes of bad input separately: a string
 * that is not an ISO date at all, and a well-formed string naming a day that
 * never existed (2026-02-30). The second is the dangerous one, because a
 * permissive parser turns it into 2026-03-02 and nobody notices.
 */
export function parseIsoDate(iso: string): CivilDate {
  if (typeof iso !== "string" || iso.length !== 10 || iso[4] !== "-" || iso[7] !== "-" || !isDigits(iso, 0, 4) || !isDigits(iso, 5, 7) || !isDigits(iso, 8, 10)) {
    throw new RangeError(`"${iso}" is not an ISO date (YYYY-MM-DD)`);
  }
  const year = Number(iso.slice(0, 4));
  const month = Number(iso.slice(5, 7));
  const day = Number(iso.slice(8, 10));
  if (year < 1) {
    throw new RangeError(`"${iso}" is outside the supported range 0001-01-01 to 9999-12-31`);
  }
  if (month < 1 || month > 12 || day < 1 || day > daysInMonth(year, month)) {
    throw new RangeError(`"${iso}" is not a real calendar date`);
  }
  return { year, month, day };
}

export function formatIsoDate(date: CivilDate): string {
  const y = String(date.year).padStart(4, "0");
  const m = String(date.month).padStart(2, "0");
  const d = String(date.day).padStart(2, "0");
  return `${y}-${m}-${d}`;
}

/** Days from 1970-01-01 to a civil date. Assumes the date has been validated. */
export function daysFromCivil(year: number, month: number, day: number): number {
  // March-based years put the leap day last, so the month-length pattern
  // becomes a simple linear formula and no special case for February is needed.
  const y = year - (month <= 2 ? 1 : 0);
  const era = Math.floor(y / 400);
  const yearOfEra = y - era * 400;
  const dayOfYear = Math.floor((153 * (month + (month > 2 ? -3 : 9)) + 2) / 5) + day - 1;
  const dayOfEra = yearOfEra * 365 + Math.floor(yearOfEra / 4) - Math.floor(yearOfEra / 100) + dayOfYear;
  return era * 146097 + dayOfEra - 719468;
}

/** The exact inverse of daysFromCivil. */
export function civilFromDays(epochDay: number): CivilDate {
  // 146097 days is exactly 400 years, which is why the Gregorian calendar
  // repeats on that cycle and why this conversion needs no lookup table.
  const z = epochDay + 719468;
  const era = Math.floor(z / 146097);
  const dayOfEra = z - era * 146097;
  const yearOfEra = Math.floor((dayOfEra - Math.floor(dayOfEra / 1460) + Math.floor(dayOfEra / 36524) - Math.floor(dayOfEra / 146096)) / 365);
  const y = yearOfEra + era * 400;
  const dayOfYear = dayOfEra - (365 * yearOfEra + Math.floor(yearOfEra / 4) - Math.floor(yearOfEra / 100));
  const monthPrime = Math.floor((5 * dayOfYear + 2) / 153);
  const day = dayOfYear - Math.floor((153 * monthPrime + 2) / 5) + 1;
  const month = monthPrime + (monthPrime < 10 ? 3 : -9);
  return { year: y + (month <= 2 ? 1 : 0), month, day };
}

/** An ISO date as a day number counted from 1970-01-01. Negative before then. */
export function epochDayFromIso(iso: string): number {
  const date = parseIsoDate(iso);
  return daysFromCivil(date.year, date.month, date.day);
}

/** The inverse: a day number back to an ISO date, refusing years outside 0001-9999. */
export function isoFromEpochDay(epochDay: number): string {
  if (!Number.isInteger(epochDay) || epochDay < MIN_EPOCH_DAY || epochDay > MAX_EPOCH_DAY) {
    throw new RangeError(`day ${epochDay} is outside the supported range 0001-01-01 to 9999-12-31`);
  }
  return formatIsoDate(civilFromDays(epochDay));
}

/**
 * Shift an ISO date by a whole number of days, forwards or backwards.
 *
 * Month ends and leap days need no special handling: the shift happens on the
 * day number, so 2024-02-28 + 1 is 2024-02-29 and 2026-02-28 + 1 is
 * 2026-03-01 for the same reason, without a branch for either.
 */
export function addDays(iso: string, days: number): string {
  if (!Number.isInteger(days)) {
    throw new TypeError(`days must be an integer, received ${days}`);
  }
  return isoFromEpochDay(epochDayFromIso(iso) + days);
}

/** Whole days from one date to another, negative when the second is earlier. */
export function daysBetween(startIso: string, endIso: string): number {
  return epochDayFromIso(endIso) - epochDayFromIso(startIso);
}

Install

fune build

With that line in your source, in a TypeScript project (language typescript in fune.project), fune build resolves it and nothing else, pins them in fune.lock, downloads only the TypeScript package of each, and builds the code above into your project’s .fune/build, one readable file per capability with a header linking back here. Or pin a range in fune.project and build in one step:

fune add dates.add-days
Download for TypeScript dates.add-days-1.0.0-typescript.fune · 13,011 bytes sha256 8ac31bd892373c0661c4190af278ad458d8e7491910525a7bf3e315178780095

The manifest, vectors and README with only the TypeScript implementation. Install it without the registry with fune add ./dates.add-days-1.0.0-typescript.fune, or fetch it from a terminal with fune pull dates.add-days@1.0.0:typescript.

The whole function, every language, is one file too: dates.add-days-1.0.0.fune, 26,107 bytes, sha256 c8546db9870fee4bc128650b0c3801cf6b3a0bc4daa6338c53a5f3b6d15a79e5. It installs into a project of any language.

Customise it in your app

The seams this capability offers. Put a marker directly above a function of your own and fune build wires it into the built code; the package on the registry is not changed, the built file’s header lists it under CUSTOMISED, and fune hooks lists every hook in the project. How hooks work.

before — your function gets the arguments and returns them, changed or not, or throws to refuse the call.

// fune: before dates.add-days

after — your function gets the result and the arguments, and returns the final result.

// fune: after dates.add-days

replace — it requires no other capability, so there is no dependency to replace.

step — your function runs at a numbered point inside the function’s body, receives the in-scope values it names as parameters, and may return replacements. List the points with fune show dates.add-days --steps.

// fune: step dates.add-days after <n|label>

Tests

A version published now needs at least 8 tests for every function, and one that expects the error for each function that throws; the registry refuses it otherwise. fune verify --all runs each case in TypeScript, Python and Rust, and a project runs them again with fune verify. This page lists the cases; it does not run them. The exact JSON is vectors.json.

CaseArgumentsExpected
one day forward mid-month 2026-09-16, 1 → 2026-09-17
zero days is the same date back 2026-09-16, 0 → 2026-09-16
2024 is a leap year so 28 February is followed by the 29th 2024-02-28, 1 → 2024-02-29
2026 is not a leap year so 28 February rolls into March 2026-02-28, 1 → 2026-03-01
1900 was a century year and not a leap year 1900-02-28, 1 → 1900-03-01
2000 was divisible by 400 and was a leap year 2000-02-28, 1 → 2000-02-29
2100 is a century year and will not be a leap year 2100-02-28, 1 → 2100-03-01
31 January rolls to 1 February, never to 3 March 2026-01-31, 1 → 2026-02-01
31 March rolls to 1 April 2026-03-31, 1 → 2026-04-01
year rollover 2026-12-31, 1 → 2027-01-01
Show the other 18 tests
CaseArgumentsExpected
year rollover into a leap year 1999-12-31, 1 → 2000-01-01
negative offset crosses back over new year 2027-01-01, -1 → 2026-12-31
negative offset lands on the leap day 2024-03-01, -1 → 2024-02-29
negative offset skips the leap day that does not exist 1900-03-01, -1 → 1900-02-28
365 days in a common year lands on the same date 2025-03-01, 365 → 2026-03-01
365 days across a leap day lands a day short 2024-01-01, 365 → 2024-12-31
a large negative offset 2026-09-16, -1,000 → 2023-12-21
a large positive offset 2026-09-16, 10,000 → 2054-02-01
dates before the 1970 epoch work the same way 1969-12-31, 1 → 1970-01-01
a slash-separated date is an error, not a guess 16/09/2026, 1 → error: is not an ISO date
an unpadded month is an error 2026-9-16, 1 → error: is not an ISO date
a date with a time attached is an error 2026-09-16T00:00:00Z, 1 → error: is not an ISO date
30 February is not a real date and is not silently rolled forward 2026-02-30, 1 → error: is not a real calendar date
29 February in a non-leap year is rejected 2026-02-29, 1 → error: is not a real calendar date
month 13 is rejected 2026-13-01, 1 → error: is not a real calendar date
31 April is rejected 2026-04-31, 1 → error: is not a real calendar date
a fractional day count is an error 2026-09-16, 1.5 → error: days must be an integer
running off the end of the supported range is an error 9999-12-31, 1 → error: outside the supported range

More from the author

Impossible dates are rejected rather than normalised. 2026-02-30 is an error, not 2026-03-02: a parser that silently rolls a bad date forward turns a data-entry mistake into a plausible wrong answer.

Supported range is 0001-01-01 to 9999-12-31, the dates a four-digit ISO year can express. Inside that range every division in the kernel has non-negative operands, so truncating division in Rust, floor division in Python and Math.floor in TypeScript all agree.

Files

PathBytes
README.md1,255
impl/python.py5,846
impl/rust.rs6,800
impl/typescript.ts6,218
vectors.json3,217