ஒரு தேதியில் மாதங்களை சேர்ப்பது எத்தனை கடினம் என்று தெரியுமா

ஒரு தேதியில் 7 நாட்கள் சேர்ப்பது எளிது. ஒரு எண்ணை எடுத்து 7 சேர்த்தால் முடிந்தது. ஒரு மாதம் சேர்ப்பது முற்றிலும் வேறு ஒரு பிரச்சனை.

சிரமம் என்னவென்றால் மாதங்களுக்கு வெவ்வேறு நீளங்கள் உள்ளன. ஜனவரியில் 31 நாட்கள் உள்ளன. பிப்ரவரியில் 28, சில நேரங்களில் 29 நாட்கள். நீங்கள் ஜனவரி 31 இல் இருந்து ஒரு மாதம் சேர்த்தால், பிப்ரவரி 31 இல் தரையிறங்குவீர்கள் — அது இல்லாத தேதி.

ஒவ்வொரு காலெண்டர் நூலகம், விரிதாள் மற்றும் தரவுத்தளமும் அடுத்து என்ன செய்வது என்பதில் வேறுபட்ட கருத்து கொண்டுள்ளது.

பெரும்பாலான கருவிகள் என்ன செய்கின்றன

மிகவும் பொதுவான நடவடிக்கை என்னவென்றால், இலக்கு மாதத்தின் கடைசி நாளுக்கு நகர்வது. ஜனவரி 31 + 1 மாதம் = பிப்ரவரி 28 (அல்லது லீப் ஆண்டில் 29). மார்ச் 31 + 1 மாதம் = ஏப்ரல் 30.

இது end-of-month clamping என்று அழைக்கப்படுகிறது, இது Excel, Google Sheets, Python இன் dateutil, மற்றும் பெரும்பாலான தேதி நூலகங்கள் இயல்பாக செய்வது.

இது நியாயமானது, ஆனால் இது ஒரு நுட்பமான பிரச்சனையை உருவாக்குகிறது: செயல்பாடு மீளக்கூடியதல்ல. ஜனவரி 31 க்கு ஒரு மாதம் சேர்த்தால், பிப்ரவரி 28 கிடைக்கும். பின்னர் ஒரு மாதம் கழித்தால், ஜனவரி 28 கிடைக்கும் — ஜனவரி 31 அல்ல. மூன்று நாட்களை இழந்துவிட்டீர்கள்.

overflow அணுகுமுறை

சில அமைப்புகள் clamping க்கு பதிலாக தேதியை அடுத்த மாதத்திற்கு overflow ஆக அனுமதிக்கின்றன. ஜனவரி 31 + 1 மாதம் = மார்ச் 3 (அல்லது லீப் ஆண்டில் மார்ச் 2, ஏனெனில் பிப்ரவரியில் 29 நாட்கள் உள்ளன).

இது மொத்த நாட்கள் எண்ணிக்கையை பாதுகாக்கிறது, ஆனால் நீங்கள் திட்டமிட்டதை விட முற்றிலும் வேறு மாதத்தில் முடிவு கிடைக்கும். இது ஆச்சரியமளிக்கிறது மற்றும் பொதுவாக பயனரின் பார்வையில் தவறானது.

சில தரவுத்தளங்களில் SQL இன் INTERVAL தொடரியல் கட்டமைப்பைப் பொறுத்து இதைச் செய்கிறது. நீங்கள் எந்த நடவடிக்கையுடன் பணிபுரிகிறீர்கள் என்று தெரியாவிட்டால் எளிதாக தவறு நடக்கும்.

ஆண்டுகளை சேர்ப்பதிலும் அதே பிரச்சனை

பிப்ரவரி 29 லீப் ஆண்டுகளில் மட்டுமே உள்ளது. பிப்ரவரி 29, 2024 க்கு ஒரு ஆண்டு சேர்த்தால், பிப்ரவரி 29, 2025 கிடைக்கும் — அது இல்லாத தேதி. Clamping பிப்ரவரி 28, 2025 ஐ தருகிறது.

அதே நடவடிக்கை, அதே நன்மை-தீமைகள்.

இது உண்மையில் எப்போது பிழைகளை ஏற்படுத்துகிறது

Subscription billing என்பது பாரம்பரிய உதாரணம். ஒரு பயனர் ஜனவரி 31 அன்று பதிவு செய்கிறார். அவர்களின் அடுத்த billing தேதி பிப்ரவரி 28. பின்னர் மார்ச் 28. பின்னர் ஏப்ரல் 28. முதல் மாதத்திற்குப் பிறகு ஒவ்வொரு மாதமும், அவர்கள் எதிர்பார்ப்பதை விட 2-3 நாட்கள் முன்னதாக பில் செய்யப்படுகிறார்கள்.

மீண்டும் நிகழும் காலெண்டர் நிகழ்வுகளுக்கும் அதே பிரச்சனை. "ஒவ்வொரு மாதமும் 31 ஆம் தேதி" என்பது 31 க்கு எட்டாத மாதங்களில் "ஒவ்வொரு மாதமும் கடைசி நாள்" என்று மாறுகிறது.

கடன் திருப்பிச் செலுத்தும் அட்டவணைகள், சம்பள தேதிகள் மற்றும் "மாதாந்திர" மறுநிகழ்வுடன் எதுவும் இந்த edge case ஐ இறுதியில் எதிர்கொள்கின்றன.

நாட்களை சேர்ப்பதில் இந்த பிரச்சனை இல்லை

"ஒரு மாதம் இப்போதிருந்து" என்பதற்கு பதிலாக "இப்போதிருந்து 30 நாட்கள்" என்று வெளிப்படுத்த வேண்டுமென்றால், வெறும் 30 நாட்கள் சேர்க்கவும். முடிவு தெளிவற்றது இல்லாமல் மீளக்கூடியது.

வேறுபாடு முக்கியம்: 30 நாள் billing சுழற்சி மற்றும் மாதாந்திர billing சுழற்சி ஒரே மாதிரியானது அல்ல, அவை காலப்போக்கில் விரைவாக வேறுபடுகின்றன.

உங்கள் கருவி அல்லது நூலகத்தில் என்ன சரிபார்க்க வேண்டும்

எந்தவொரு அமைப்பிலும் தேதி சேர்த்தலை நம்புவதற்கு முன், இவற்றை அறிவது மதிப்பு:

• மாத-இறுதி தேதிகளில் அது clamp செய்கிறதா அல்லது overflow ஆகிறதா?
• பல சேர்த்தல்களில் மாதத்தின் நாளை பாதுகாக்கிறதா, அல்லது ஒவ்வொரு முறையும் re-clamp செய்கிறதா?
• லீப் ஆண்டு edge cases க்கு, பிப். 29 + 1 ஆண்டுக்கு என்ன நடக்கும்?

தேதி கணிப்பான் எந்த தேதி மற்றும் offset க்கும் சரியான முடிவைக் காட்டுகிறது — குறியீட்டில் கணக்கீட்டை உறுதிப்படுத்துவதற்கு முன் சரிபார்க்க பயனுள்ளது.