Ang pagdagdag ng buwan sa isang petsa ay mas mahirap kaysa sa tingin
Madali ang pagdagdag ng 7 araw sa isang petsa. Kukunin mo ang isang numero, idaragdag mo ang 7, tapos na. Ang pagdagdag ng isang buwan ay ibang problema nang lubusan.
Ang problema ay may iba't ibang haba ang mga buwan. Ang Enero ay may 31 araw. Ang Pebrero ay may 28, kung minsan 29. Kung nasa Enero 31 ka at magdagdag ng isang buwan, makakarating ka sa Pebrero 31 — na hindi umiiral.
Bawat calendar library, spreadsheet, at database ay may sariling ideya kung ano ang gagawin pagkatapos.
Kung ano ang ginagawa ng karamihan ng tools
Ang pinaka-karaniwang pag-uugali ay umabay sa huling araw ng target month. Enero 31 + 1 buwan = Pebrero 28 (o 29 sa leap year). Marzo 31 + 1 buwan = Abril 30.
Ito ay tinatawag na end-of-month clamping at ito ang ginagawa ng Excel, Google Sheets, Python's dateutil, at karamihan ng date libraries bilang default.
Ito ay makatuwirang gawin, pero lumilikha ito ng isang subtil na problema: ang operasyon ay hindi mababawi. Kung magdagdag ka ng isang buwan sa Enero 31, makukuha mo ang Pebrero 28. Kung magbabawas ka ng isang buwan, makukuha mo ang Enero 28 — hindi Enero 31. Nawala mo ang tatlong araw.
Ang overflow approach
Ang ilang sistema ay nagpapayagan sa petsa na mag-overflow sa susunod na buwan imbes na mag-clamp. Enero 31 + 1 buwan = Marzo 3 (o Marzo 2 sa leap year, dahil ang Pebrero ay may 29 araw).
Ito ay nagpapanatili ng kabuuang bilang ng araw ngunit ang resulta ay nakarating sa isang ganap na magkakaibang buwan kaysa sa inaasahan mo. Ito ay nakakamangha at karaniwang hindi tama mula sa perspektibo ng user.
Ang INTERVAL syntax ng SQL sa ilang databases ay gumagawa nito depende sa configuration. Madaling masugatan kung hindi ka kaalam kung aling pag-uugali ang gumagana mo.
Ang pagdagdag ng taon ay may parehong isyu
Ang Pebrero 29 ay umiiral lamang sa leap years. Magdagdag ng isang taon sa Pebrero 29, 2024, at makukuha mo ang Pebrero 29, 2025 — na hindi umiiral. Ang clamping ay nagbibigay sa iyo ng Pebrero 28, 2025.
Parehong pag-uugali, parehas na mga tradeoffs.
Kailan ito tunay na nagdudulot ng bugs
Ang subscription billing ay ang klasikong halimbawa. Ang isang user ay nag-sign up sa Enero 31. Ang kanilang susunod na billing date ay Pebrero 28. Pagkatapos Marzo 28. Pagkatapos Abril 28. Bawat buwan pagkatapos ng una, sila ay nababinisuhan 2-3 araw na mas maaga kaysa sa inaasahan nila.
Ang recurring calendar events ay may parehong isyu. Ang "bawat buwan sa ika-31" ay tahimik na nagiging "bawat buwan sa huling araw" para sa mga buwang hindi umabot sa 31.
Ang loan repayment schedules, payroll dates, at kahit anumang may "monthly" recurrence ay aabot sa edge case na ito sa huli.
Ang pagdagdag ng araw ay walang ganitong problema
Kung kailangan mo ipahayag ang "30 araw mula ngayon" sa halip na "isang buwan mula ngayon," magdagdag lamang ng 30 araw. Ang resulta ay malinaw at mababawi.
Ang pagkakaiba ay mahalaga: ang 30-day billing cycle at ang monthly billing cycle ay hindi pareho, at sila ay magkakaiba nang mabilis sa paglipas ng panahon.
Kung ano ang susuriin sa iyong tool o library
Bago magtiwala sa date addition sa anumang sistema, sulit na malaman:
- Lumalaki o umaagos ito sa month-end dates?
- Pinapanatili nito ang day-of-month sa maraming pagdaragdag, o muling nag-clamp bawat pagkakataon?
- Para sa leap year edge cases, ano ang nangyayari sa Peb 29 + 1 taon?
Ang Date Calculator ay nagpapakita sa iyo ng eksaktong resulta para sa anumang petsa at offset — kapaki-pakinabang para sa sanity-checking bago ka kumilos sa isang kalkulasyon sa code.
