सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
विज़िटर के समय क्षेत्र के अनुसार तारीख और समय के प्रारूप स्थानीय बनाएँ
आपके सर्वर के समय क्षेत्र में दिखाया गया टाइमस्टैम्प लगभग किसी के लिए सही नहीं पढ़ा जाता, सिवाय उसके जो संयोग से उसी क्षेत्र में बैठा हो, और हर जगह से आने वाले विज़िटर वाली साइट के लिए इसका मतलब लगभग कोई भी नहीं है।
विज़िटर का समय क्षेत्र पता करना
IP लुकअप सीधे एक timezone फ़ील्ड लौटाता है, जिससे आपको पेज पर किसी भी टाइमस्टैम्प को स्थानीय बनाने के लिए ज़रूरी पहचानकर्ता मिल जाता है।
GET /v1/ip?ip=203.0.113.77{
"status": "ok",
"ip": "203.0.113.77",
"version": 4,
"found": true,
"country": "Brazil",
"country_code": "BR",
"region": "Rio de Janeiro",
"city": "Rio de Janeiro",
"postcode": "20040",
"lat": -22.9068,
"lon": -43.1729,
"timezone": "America/Sao_Paulo",
"asn": 5566,
"org": "Example ISP"
}संग्रहीत टाइमस्टैम्प बदलना
हमेशा की तरह अपने डेटाबेस में हर टाइमस्टैम्प UTC में संग्रहीत करें, और केवल दिखाते समय, सर्वर पर, लुकअप से मिले timezone पहचानकर्ता का उपयोग करके विज़िटर के स्थानीय समय क्षेत्र में बदलें। चूँकि यह साइट बिना किसी क्लाइंट-साइड JavaScript के सब कुछ सर्वर पर रेंडर करती है, बदलाव और फ़ॉर्मेटिंग दोनों पेज भेजे जाने से पहले होते हैं, बाद में ब्राउज़र में नहीं।
local_time = convert_to_timezone(stored_utc_timestamp, "America/Sao_Paulo")दूसरा उदाहरण: ऑर्डर पुष्टि का टाइमस्टैम्प
"ऑर्डर का समय" और "अनुमानित पहुँच" का समय दिखाने वाला ऑर्डर पुष्टि पेज एक अच्छा उदाहरण है कि यह किसी साधारण पेज हेडर घड़ी से आगे कहाँ मायने रखता है। दोनों टाइमस्टैम्प को उसी विज़िटर समय क्षेत्र से बदलने से, बजाय गलती से एक को सर्वर समय में छोड़ देने के, दोनों आँकड़े सुसंगत रहते हैं और वह उलझन भरी स्थिति नहीं आती जहाँ अनुमानित डिलीवरी का समय ऑर्डर के समय से पहले दिखता है क्योंकि एक को बदला गया और दूसरे को नहीं।
सिर्फ़ बदलना नहीं, फ़ॉर्मेट करना भी
समय क्षेत्र और फ़ॉर्मेट आपस में जुड़े हैं लेकिन अलग-अलग चुनाव हैं। ऐसे क्षेत्र का विज़िटर जहाँ आम तौर पर 24-घंटे की घड़ी और दिन-महीना-वर्ष का तारीख क्रम इस्तेमाल होता है, उसे मेल खाती फ़ॉर्मेटिंग से फ़ायदा होता है, न कि सिर्फ़ खिसकाए गए घंटे के मान से जो ऐसे फ़ॉर्मेट में लिखा हो जो अब भी पराया लगे। अगर आप सिर्फ़ घंटा समायोजित करने से आगे जाना चाहते हैं, तो उसी IP लुकअप से मिले country_code को एक छोटी फ़ॉर्मेटिंग लुकअप टेबल के साथ जोड़ें।
एक आम गलती जिससे बचना चाहिए
बदलाव को ऐसे स्थिर घंटे के ऑफ़सेट के रूप में लागू न करें जिसकी गणना एक बार की जाए और आगे हर टाइमस्टैम्प पर लागू की जाए। किसी समय क्षेत्र का UTC से असली ऑफ़सेट साल भर में डेलाइट सेविंग के साथ बदल सकता है, इसलिए एक मौसम में सही बदला गया टाइमस्टैम्प दूसरे मौसम में एक घंटा गलत आ सकता है, अगर कोड किसी सही तारीख और समय लाइब्रेरी से timezone पहचानकर्ता के ज़रिए बदलने के बजाय संग्रहीत ऑफ़सेट संख्या लागू करता है।
एक असामान्य मामला: पूरे घंटे से अलग ऑफ़सेट
हर समय क्षेत्र UTC से पूरे घंटे के ऑफ़सेट पर नहीं होता। कुछ पूरे घंटे के बजाय 30 या 45 मिनट के ऑफ़सेट पर होते हैं। किसी सरल, सिर्फ़ घंटे वाले ऑफ़सेट मान के बजाय पूरे IANA समय क्षेत्र पहचानकर्ता को समझने वाली तारीख लाइब्रेरी पर भरोसा करने से यह आपकी तरफ़ से किसी विशेष कोड के बिना सही ढंग से संभल जाता है। अगर आप बदले गए समय के साथ ऑफ़सेट को स्पष्ट रूप से दिखाना चाहते हैं, तो timezone लुकअप दस्तावेज़ में बताए गए utc_offset और abbreviation फ़ील्ड उपयोगी हैं।
सेशन के लिए समय क्षेत्र को कैश करना
हर विज़िटर सेशन में समय क्षेत्र एक बार लुकअप करें और उस विज़िट के दौरान हर पेज पर रेंडर होने वाले हर टाइमस्टैम्प के लिए उसी का दोबारा उपयोग करें, बजाय दिखाई गई हर अलग तारीख के लिए API को फिर से कॉल करने के, क्योंकि सेशन के बीच में समय क्षेत्र नहीं बदलता।
पूरी साइट को स्थानीय बनाने की लागत
हर नए सेशन में एक लुकअप उस विज़िट के दौरान दिखाए गए हर टाइमस्टैम्प का स्थानीयकरण कवर कर देता है, एक अनुरोध, चाहे पेज पर कितनी भी तारीखें हों। इससे भारी कंटेंट वाली साइट भी हर कुंजी के साथ शामिल प्रतिदिन 2,500 मुफ़्त अनुरोधों के भीतर आराम से रहती है।
पूरी साइट पर स्थानीय समय और तारीख की फ़ॉर्मेटिंग सही करना हर सेशन में एक लुकअप और उसके बाद सुसंगत सर्वर-साइड रेंडरिंग पर निर्भर है। IPv4 लुकअप दस्तावेज़ और timezone लुकअप दस्तावेज़ समय क्षेत्र पता करने के दोनों तरीकों को कवर करते हैं।