Å legge til måneder på en dato er vanskeligere enn det høres ut

Å legge til 7 dager på en dato er enkelt. Du tar et tall og legger til 7, ferdig. Å legge til en måned er en helt annen problemstilling.

Problemet er at måneder har ulik lengde. Januar har 31 dager. Februar har 28, noen ganger 29. Hvis du er på 31. januar og legger til en måned, lander du på 31. februar — som ikke eksisterer.

Ethvert kalenderbibliotek, regneark og database har en mening om hva som skal gjøres videre.

Hva de fleste verktøy gjør

Den vanligste oppførselen er å hoppe til siste dag i målmåneden. 31. januar + 1 måned = 28. februar (eller 29 i et skuddår). 31. mars + 1 måned = 30. april.

Dette kalles sluttmåned-begrensning og det er det Excel, Google Sheets, Python sin dateutil, og de fleste datobiblioteker gjør som standard.

Det er fornuftig, men det skaper et subtilt problem: operasjonen er ikke reversibel. Hvis du legger til en måned på 31. januar, får du 28. februar. Hvis du så trekker fra en måned, får du 28. januar — ikke 31. januar. Du har mistet tre dager.

Overflødighetsmetoden

Noen systemer lar datoen flyte over i neste måned i stedet for å bli begrenset. 31. januar + 1 måned = 3. mars (eller 2. mars i et skuddår, siden februar har 29 dager).

Dette bevarer den totale dagtellingen, men resultatet lander i en helt annen måned enn du hadde til hensikt. Det er overraskende og vanligvis galt fra brukerens perspektiv.

SQL sin INTERVAL-syntaks i noen databaser gjør dette avhengig av innstillinger. Det er lett å bli brent hvis du ikke er klar over hvilken oppførsel du jobber med.

Å legge til år har samme problem

31. februar eksisterer bare i skuddår. Legg til ett år på 29. februar 2024, og du får 29. februar 2025 — som ikke eksisterer. Begrensning gir deg 28. februar 2025.

Samme oppførsel, samme avveininger.

Når dette faktisk forårsaker feil

Abonnementsfakturering er det klassiske eksempelet. En bruker registrerer seg 31. januar. Deres neste faktureringsdato er 28. februar. Deretter 28. mars. Deretter 28. april. Hver måned etter den første faktureres de 2–3 dager tidligere enn de forventer.

Gjentakende kalenderbegivenheter har samme problem. "Hver måned på den 31." blir stille "hver måned på siste dag" for måneder som ikke når 31.

Lånebetalingsplaner, lønnsdatoer og alt med «månedlig» gjentakelse treffer denne edge casen til slutt.

Å legge til dager har ikke dette problemet

Hvis du trenger å uttrykke «30 dager fra nå» i stedet for «en måned fra nå», legger du bare til 30 dager. Resultatet er entydig og reversibel.

Skillet er viktig: en 30-dagers faktureringssyklus og en månedlig faktureringssyklus er ikke det samme, og de avviker raskt over tid.

Hva du bør sjekke i verktøyet eller biblioteket ditt

Før du stoler på datoaddisjon i et system, er det verdt å vite:

• Begrenser eller overflødiger den på slutten av måneden?
• Bevarer den dagen-i-måneden ved flere addisjoner, eller begrenses den på nytt hver gang?
• For skuddårs-edge cases, hva skjer på 29. feb + 1 år?

Date Calculator viser deg det nøyaktige resultatet for hvilken som helst dato og offset — nyttig for å dobbelsjekke før du forplikter deg til en beregning i kode.