Share one date formatter, and stop describing files that are gone

Two components each carried the same four lines turning a date into an ISO
string from local parts. They now share one helper, deliberately separate
from the one that formats in UTC: substituting one for the other shifts the
day by one anywhere east of Greenwich, Sweden included, so a test pins the
difference rather than a comment asking nicely.

Creating a period ran its own copy of the sync-and-report sequence purely so
it could name a wish the lookup could not yet see; it now passes that wish to
the ordinary path instead.

Two comments still explained their relationship to components deleted some
time ago, which would send the next reader looking for files that are not
there, and some styling outlived the markup it described.
This commit is contained in:
2026-09-18 01:12:58 +02:00
parent 9ac67933d4
commit f2b3920cbc
8 changed files with 112 additions and 99 deletions
+19
View File
@@ -45,6 +45,25 @@ export function formatDateForInput(date: string | Date): string {
return `${year}-${month}-${day}`
}
/**
* Format a Date's *local* calendar date as YYYY-MM-DD, using
* getFullYear/getMonth/getDate rather than the UTC getters.
*
* This is deliberately NOT `formatDateForInput`, which uses UTC getters and
* assumes the Date was built from an ISO string at UTC midnight. Callers
* here (the calendar grid) build Dates from local year/month/day components
* (`new Date(year, month, day)`), so reading them back with UTC getters
* would shift the date by one day in any timezone ahead of UTC (Sweden
* included). Do not "consolidate" this with `formatDateForInput` — they
* serve different Date constructions and are not interchangeable.
*/
export function formatDateLocalISO(date: Date): string {
const year = date.getFullYear()
const month = String(date.getMonth() + 1).padStart(2, '0')
const day = String(date.getDate()).padStart(2, '0')
return `${year}-${month}-${day}`
}
/**
* Parse an ISO date string (YYYY-MM-DD) to a Date object.
*/