ec27228a8e
Em dashes (—) and en dashes (–) had spread across comments, docs, tests, and a few UI strings, reading as AI-generated boilerplate rather than house style. Replaced each with punctuation matching its context: colon for explanatory clauses, comma for asides, plain hyphen for numeric/legal ranges (e.g. "21-23§"), "to"/"till" for date ranges, parentheses for paired-dash asides. messages/en.json and messages/sv.json were fixed by hand together to keep sv/en in sync. Left untouched where the dash is the functional subject rather than decorative punctuation: date-range-parser.ts's separator regex, charset-repair.ts's CP1252 byte-mapping table (and its test), the SIE encoding mojibake docs, generic-csv.ts's minus-sign normalizer, the agent system-prompt files that already instruct against em dashes, and a golden iXBRL test fixture compared byte-for-byte. Also fixes two bugs surfaced along the way: an off-by-one in ApiKeysPanel's scope-label split (a leftover from an earlier partial pass), and a charset-repair test that had lost the literal en-dash it exists to verify. Regenerated the agent atom seed migration (skills:generate) since 27 SKILL.md files changed. Added a CLAUDE.md rule against em/en dashes, with an explicit carve-out for the functional-dash cases above. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
52 lines
2.3 KiB
TypeScript
52 lines
2.3 KiB
TypeScript
import type { CompanySettings } from '@/types'
|
|
|
|
/**
|
|
* Return the ISO date (YYYY-MM-DD) for the start of the fiscal year that
|
|
* contains `today`, given the company's fiscal_year_start_month setting.
|
|
*
|
|
* Enskild firma is locked to calendar year per BFL. We assume `entity_type`
|
|
* reflects the company's *current* tax-year status: if an enskild firma is
|
|
* mid-conversion to an AB, callers should re-resolve after the conversion
|
|
* lands rather than backfilling from a stale anchor.
|
|
*/
|
|
export function getCurrentFiscalYearStart(
|
|
settings: Pick<CompanySettings, 'fiscal_year_start_month' | 'entity_type'> | null | undefined,
|
|
today: Date = new Date(),
|
|
): string {
|
|
let startMonth = settings?.fiscal_year_start_month || 1
|
|
if (settings?.entity_type === 'enskild_firma') startMonth = 1
|
|
|
|
const year = today.getMonth() + 1 >= startMonth ? today.getFullYear() : today.getFullYear() - 1
|
|
return `${year}-${String(startMonth).padStart(2, '0')}-01`
|
|
}
|
|
|
|
/**
|
|
* Return the ISO date for the start of the PREVIOUS fiscal year: useful when
|
|
* the user wants to backfill the year that just closed.
|
|
*/
|
|
export function getPreviousFiscalYearStart(
|
|
settings: Pick<CompanySettings, 'fiscal_year_start_month' | 'entity_type'> | null | undefined,
|
|
today: Date = new Date(),
|
|
): string {
|
|
let startMonth = settings?.fiscal_year_start_month || 1
|
|
if (settings?.entity_type === 'enskild_firma') startMonth = 1
|
|
|
|
const currentYearStart = today.getMonth() + 1 >= startMonth
|
|
? today.getFullYear()
|
|
: today.getFullYear() - 1
|
|
return `${currentYearStart - 1}-${String(startMonth).padStart(2, '0')}-01`
|
|
}
|
|
|
|
export function daysBetween(from: string | Date, to: string | Date = new Date()): number {
|
|
// Bare ISO date strings ("2026-01-01") are parsed as UTC midnight, but
|
|
// `new Date()` is local wall-clock time. Mixing the two means timezones east
|
|
// of UTC can be one day past UTC midnight while still on the prior local
|
|
// date, producing off-by-one drift. Pin both string operands to UTC so the
|
|
// math is timezone-independent. Date operands (rare; tests + future callers)
|
|
// are trusted as-is.
|
|
const parse = (v: string | Date) =>
|
|
typeof v === 'string' ? new Date(v + 'T00:00:00Z') : v
|
|
const diff = parse(to).getTime() - parse(from).getTime()
|
|
return Math.max(0, Math.ceil(diff / (24 * 60 * 60 * 1000)))
|
|
}
|