क्रेडिट कार्ड समाप्ति तिथि: प्रारूप, नियम और किनारे के मामले

क्रेडिट कार्ड समाप्ति तिथि प्लास्टिक पर चार अक्षरों की जगह लेती है और उसे पढ़ने वाले सॉफ़्टवेयर में अनुपात से कहीं ज़्यादा बग पैदा करती है। छपा हुआ मान छोटा है, पर वह एक साथ दो अलग नियम ढोता है: कार्ड किस महीने में काम करना बंद करता है, और उस महीने के आखिरी दिन किस समय वाकई बंद होता है। सीमा गलत लगाना उन क्लासिक तरीकों में से एक है जिनसे चेकआउट ऐसे कार्ड को ठुकरा देता है जो अभी पूरी तरह इस्तेमाल योग्य है।

आगे के खंड बताते हैं कि छपी तारीख का अर्थ क्या है, महीने के अंत का नियम कैसे काम करता है, फ़ॉर्म और डेटाबेस शायद ही कभी वही चीज़ संग्रह क्यों करते हैं जो कार्ड दिखाता है, और मुश्किल मामलों की जाँच कैसे करें।

छपी हुई तारीख का अर्थ

कार्ड पर की तारीख एक महीना और एक वर्ष होती है, दोनों दो-दो अंकों में लिखे जाते हैं, और महीना पहले आता है: उदाहरण के लिए महीना नौ और वर्ष छब्बीस, या महीना एक और वर्ष तीस। कार्ड पर कोई दिन नहीं होता, और यही भ्रम का पहला स्रोत है — लोग उसे ढूँढ़ते हैं क्योंकि बाकी हर तारीख में दिन होता है।

महीना और वर्ष बताते हैं कि कार्ड कब वैध रहना बंद करता है, यह नहीं कि वह कब जारी हुआ। कई साल आगे की तारीख वाला कार्ड सामान्य है, क्योंकि जारीकर्ता आमतौर पर समाप्ति से काफी पहले ही कार्ड बदल देते हैं।

यह मान कार्ड पर किसी और चीज़ से निकाला नहीं जाता। यह चेकसम नहीं है और नंबर के साथ इसका कोई संबंध नहीं। यह परीक्षण के लिए मायने रखता है: समाप्ति तिथि गणित से नहीं गढ़ी जा सकती, इसलिए उसे आपूर्त करना ही पड़ता है, और इसीलिए बनाए गए कार्डों के साथ तारीख जुड़ी आती है।

क्या कार्ड पूरे महीने वैध रहता है?

हाँ। यही वह नियम है जो लोगों को फँसाता है। जिस कार्ड पर कोई महीना और वर्ष छपा है, वह उस महीने के आखिरी दिन तक, उस दिन के अंतिम क्षण तक स्वीकार किया जाता है — उस समय क्षेत्र में जो जारीकर्ता की अधिकरण प्रणाली इस्तेमाल करती है।

इसलिए महीना नौ और वर्ष छब्बीस वाला कार्ड उस वर्ष की तीस सितंबर को भी चलता है, और अक्टूबर के पहले क्षण पर चलना बंद कर देता है। जो भी प्रणाली कार्ड को सितंबर की शुरुआत में, या आखिरी दिन की मध्यरात्रि पर काट देती है, वह घंटों या दिनों की अवधि के लिए वैध भुगतान ठुकरा रही है।

यह तालिका यह भी दिखाती है कि दिनों की गिनती क्यों मायने रखती है। फ़रवरी सबसे मुश्किल है, क्योंकि उसका आखिरी दिन वर्ष पर निर्भर करता है, और अट्ठाईस दिन मान लेने वाला फ़ॉर्म या निर्धारित कार्य लीप वर्ष में सीमा गलत लगाएगा।

फ़ॉर्म चार के बजाय दो अंक क्यों माँगते हैं?

कार्ड जगह बचाने के लिए वर्ष के केवल दो अंक छापते हैं, और फ़ॉर्म आमतौर पर वही दो माँगते हैं क्योंकि उपयोगकर्ता वही पढ़ रहा होता है। यह परंपरा एक फैसला सॉफ़्टवेयर पर डाल देती है: यह मान किस सदी का है?

सदी को कोड में नहीं, सामान्य भाषा में लिखें तो सामान्य दृष्टिकोण यह है कि दो अंकों के वर्ष को आज के सापेक्ष उसकी निकटता के आधार पर वर्तमान या अगली सदी का माना जाए। जो वर्ष मान बहुत पीछे लगता है, वह लगभग हमेशा टाइपिंग की गलती होती है, किसी पुराने युग का कार्ड नहीं, और गलत सदी में डिकोड किया गया मान या तो समाप्त मानकर ठुकरा दिया जाएगा या हमेशा के लिए स्वीकार होता रहेगा।

फ़ॉर्म के लिए सबसे सुरक्षित रास्ता यह है कि उपयोगकर्ता के पास जो है उसे स्वीकार करें, उसे एक बार स्पष्ट प्रतिनिधित्व में बदलें — कोई महीना और पूरा चार अंकों का वर्ष, या कोई पहला दिन और आखिरी दिन — और उसके बाद हर जगह वही प्रतिनिधित्व इस्तेमाल करें। दो अंकों के वर्षों की सीधी तुलना कभी न करें, क्योंकि वह तुलना हर पलटाव पर सदी का अर्थ चुपचाप नए सिरे से तय कर देती है।

प्रदर्शन प्रारूप और संग्रह प्रारूप अलग चीज़ें हैं

जो श्रृंखला ग्राहक देखता है और जो मान कोई प्रणाली रखती है, वे शायद ही कभी एक जैसे होते हैं, और दोनों को मिला देना दोषों का भरोसेमंद स्रोत है।

कार्ड पर और किसी इनपुट फ़ील्ड में मान महीने के दो अंकों और वर्ष के दो अंकों के रूप में दिखता है। डेटाबेस में इसे अक्सर महीने की पहली तारीख के रूप में, या महीने और वर्ष के अलग-अलग पूर्णांक स्तंभों के रूप में, या वैधता के अंतिम क्षण के टाइमस्टैम्प के रूप में रखा जाता है। हर चुनाव के परिणाम होते हैं। महीने की पहली तारीख का टाइमस्टैम्प क्रमबद्ध करने और तुलना करने में आसान है, पर वह यह नहीं बताता कि कार्ड कब समाप्त होता है, जब तक आप महीने के अंत का नियम भी न जानते हों। अंतिम क्षण का टाइमस्टैम्प सही सीमा दर्ज करता है, पर किसी प्रशासनिक स्क्रीन पर डरावना लगता है जहाँ कोई समाप्ति के बगल में दिन का समय देखने की उम्मीद नहीं करता।

कोई भी प्रतिनिधित्व चुनें, रूपांतरण एक ही जगह रखें। उत्पादन में दिखने वाला बग आमतौर पर दूसरा रूपांतरण होता है, जिसे किसी ऐसे व्यक्ति ने लिखा जिसे पहले के अस्तित्व का पता ही नहीं था, और दोनों में एक महीने का अंतर निकल आता है।

समाप्ति तिथि भरते समय आम गलतियाँ

इस फ़ील्ड पर लोग जो गलतियाँ करते हैं उनकी सूची छोटी है, और हर एक का एक समझदार उत्तर है:

• दो अंकों वाले फ़ील्ड में वर्ष चार अंकों में टाइप कर देना। यदि स्पष्ट रूप से मिलाया जा सके तो स्वीकार करें, और शुरुआती अक्षर चुपचाप न गिराएँ।
• महीने और वर्ष की अदला-बदली। महीना तेरह और वर्ष अट्ठाईस, दोनों अमान्य हैं, इसलिए हर हिस्से को उसकी अपनी सीमा के सामने जाँचें, केवल उनके जोड़ को नहीं।
• ऐसे फ़ील्ड में शून्य से शुरू होने वाला महीना भर देना जो एक अंक की अपेक्षा करता है। एक और शून्य-एक को एक ही महीना मानें।
• ऐसा मान चिपका देना जिसमें ऐसा विभाजक हो जिसकी फ़ील्ड अपेक्षा नहीं करता, जैसे स्लैश की जगह हाइफ़न।
• ऐसी तारीख भर देना जो बीत चुकी है, जिसे फ़ॉर्म को केवल चिह्नित नहीं करना चाहिए बल्कि समझाना चाहिए।

डेवलपर के लिए: इनपुट नियंत्रण और सीमा परीक्षण

दो छोटे नियंत्रण इस अधिकांश कष्ट को रोक देते हैं। पहला, महीने और वर्ष को अलग-अलग इनपुट बनाएं, या एक ऐसा फ़ील्ड रखें जो अपेक्षित आकार को दिखाई देने वाले ढंग से निर्देशित करे, ताकि बदला हुआ मान केवल पकड़ में आने योग्य न रहे बल्कि होने की संभावना ही कम हो जाए। दूसरा, जोड़ को जाँचने से पहले हर हिस्से को उसकी अपनी सीमा के सामने जाँचें, ताकि उपयोगकर्ता जान सके कि गलत हिस्सा कौन सा है।

सीमा तर्क के लिए सीमा के दोनों सिरे जाँचें, बीच का नहीं। लिखने योग्य चार मामले हैं: छपे महीने का पहला दिन, छपे महीने का आखिरी दिन, आखिरी दिन के बाद का दिन, और वही आखिरी-दिन का मामला लीप वर्ष में। महीने के बीच पर लिखा टेस्ट उस नियम के बारे में लगभग कुछ सिद्ध नहीं करता जिसकी आप रक्षा करना चाहते हैं।

इसके बाद देखें कि घड़ी आगे बढ़ने पर आपकी प्रणाली कैसा व्यवहार करती है। यदि संग्रहित समाप्ति सबमिट के क्षण एक बार बदली जाती है और फिर कभी नहीं देखी जाती, तो महीने की सीमा के आर-पार खुला छोड़ा गया फ़ॉर्म ऐसी तारीख सबमिट कर देगा जो अभी-अभी अमान्य हुई है। जानबूझकर तय करें कि यह दिखाने योग्य त्रुटि है या स्वीकार्य किनारा, और सुनिश्चित करें कि भुगतान अनुरोध और आपके अपने रिकॉर्ड इस पर सहमत हों।

कार्ड टूल से मेल खाती समाप्ति पाना

कार्ड नंबर जनरेटर से निकला हर कार्ड ऐसी समाप्ति तिथि के साथ आता है जो उसी परंपरा में बैठती है: भविष्य का कोई महीना और वर्ष, और पूरे बैच में एक जैसी। यही एकरूपता फ़िक्स्चर के समूह को उपयोगी बनाती है — नंबर को तारीख के साथ जोड़ने वाला टेस्ट मानता है कि जोड़ी उतनी अवधि तक वैध रहेगी जितनी अवधि तक सूट चलेगा, और यही एक कारण है कि बनाया गया डेटा हाथ से मान गढ़ने के बजाय संरचना में सही और कभी जारी न किया गया रखा जाता है।

यदि कई कार्डों की एक ही समाप्ति चाहिए, तो बैच बनाकर उसमें से चुनें, तारीख दोबारा टाइप न करें, क्योंकि फ़िक्स्चर फ़ाइल में गलत टाइप किया गया एक वर्ष पकड़ में नहीं आता। भुगतान फ़ॉर्म जाँच सूची इस फ़ील्ड के आसपास के व्यापक प्रवाहों को कवर करती है, और सुरक्षा कोड गाइड उन बाकी चार अक्षरों की व्याख्या करती है जो ग्राहक कार्ड से पढ़ता है।

आगे क्या करें

लिखित रूप में तय करें कि आपकी प्रणाली के लिए समाप्ति तिथि का अर्थ क्या है — कोई महीना, कोई पहला दिन या कोई अंतिम क्षण — और उस रूपांतरण को एक ही फ़ंक्शन के पीछे रखें। इसके बाद ऊपर बताए गए चार सीमा परीक्षण जोड़ें, लीप वर्ष का मामला समेत, और पुष्टि करें कि चालू महीने की तारीख वाला कार्ड अपने अंतिम दिन भी स्वीकार होता है।