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-monthaddDays(2026-09-16, 0)→ 2026-09-16 zero days is the same date backaddDays(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
| iso | date | ISO date, YYYY-MM-DD |
| days | int | whole days to add; negative moves backwards |
| returns | date |
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";
/**
* 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
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.
| Case | Arguments | Expected | |
|---|---|---|---|
| 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
| Case | Arguments | Expected | |
|---|---|---|---|
| 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
| Path | Bytes |
|---|---|
| README.md | 1,255 |
| impl/python.py | 5,846 |
| impl/rust.rs | 6,800 |
| impl/typescript.ts | 6,218 |
| vectors.json | 3,217 |