सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
अपने उपयोगकर्ताओं के लिए UTC टाइमस्टैम्प को स्थानीय समय में बदलें
डेटाबेस के लिए टाइमस्टैम्प UTC में स्टोर करना सही फ़ैसला है। लेकिन सपोर्ट टिकट, ऑर्डर कन्फ़र्मेशन या एक्टिविटी लॉग में उपयोगकर्ता को UTC दिखाना सही नहीं है, और यह किसी प्रोडक्ट के इंटरफ़ेस की ज़्यादा आम छोटी-छोटी परेशानियों में से एक है।
दो चरणों में रूपांतरण
पहले, यह जानें कि टाइमस्टैम्प को किस जगह के हिसाब से समझा जाना चाहिए, या तो फ़ाइल में दर्ज किसी पते के निर्देशांक या IP लुकअप से मिले निर्देशांक। दूसरे, वे निर्देशांक और खुद UTC टाइमस्टैम्प time पैरामीटर का उपयोग करके /v1/timezone पर भेजें, ताकि लौटाया गया ऑफ़सेट मौजूदा पल के बजाय उसी पल से मेल खाए जिसकी बात हो रही है।
GET /v1/timezone?lat=40.7128&lon=-74.0060&time=1734000000{
"status": "ok",
"timezone": "America/New_York",
"utc_offset": "-05:00",
"abbreviation": "EST"
}utc_offset को अपने स्टोर किए गए UTC टाइमस्टैम्प पर लागू करें, या timezone आइडेंटिफ़ायर को अपने तारीख फ़ॉर्मेट करने वाले कोड में दें, और कच्चे UTC मान के बजाय नतीजा दिखाएँ।
दूसरा उदाहरण, कुछ महीनों के अंतर पर
वही निर्देशांक आपके भेजे गए टाइमस्टैम्प के अनुसार अलग ऑफ़सेट लौटाते हैं, और time पैरामीटर के होने की पूरी वजह यही है।
GET /v1/timezone?lat=40.7128&lon=-74.0060&time=1719000000{
"status": "ok",
"timezone": "America/New_York",
"utc_offset": "-04:00",
"abbreviation": "EDT"
}ध्यान दें कि ठीक उसी लोकेशन के लिए दोनों कॉल के बीच ऑफ़सेट माइनस पाँच घंटे से माइनस चार घंटे हो गया, सिर्फ़ इसलिए कि एक टाइमस्टैम्प डेलाइट सेविंग के दौरान पड़ता है और दूसरा नहीं। अगर कोई डिस्प्ले इसे नज़रअंदाज़ करके दोनों पर एक ही तय ऑफ़सेट लागू करता, तो उनमें से एक पर वह एक घंटा गलत होता।
time पैरामीटर क्यों मायने रखता है
डेलाइट सेविंग मानने वाली ज़्यादातर जगहों पर ऑफ़सेट साल भर में बदलता रहता है। अगर आप एंडपॉइंट को हमेशा बिना time पैरामीटर के ही कॉल करते हैं, तो आपको आज का ऑफ़सेट मिलता है, जो छह महीने पुराने टाइमस्टैम्प के लिए गलत होगा। जब दोनों किसी डेलाइट सेविंग बदलाव के विपरीत तरफ़ पड़ सकते हों, तो हमेशा वही टाइमस्टैम्प भेजें जिसे आप बदल रहे हैं, मौजूदा समय नहीं।
ऑफ़सेट नहीं, समय क्षेत्र को कैश करना
निर्देशांकों के किसी दिए गए सेट के लिए समय क्षेत्र आइडेंटिफ़ायर शायद ही कभी बदलता है, इसलिए timezone स्ट्रिंग को किसी लोकेशन के साथ कैश करना सुरक्षित है। utc_offset और abbreviation मानों को लंबे समय तक कैश करना सुरक्षित नहीं है, क्योंकि वे डेलाइट सेविंग के साथ बदलते हैं, इसलिए उन्हें स्टोर करने के बजाय दिखाते समय दोबारा निकालें।
एक विशेष मामला जो जानने लायक है
हर लोकेशन डेलाइट सेविंग मानती ही नहीं। जो लोकेशन साल भर एक तय ऑफ़सेट पर रहती है, वह आप कोई भी टाइमस्टैम्प भेजें, वही utc_offset लौटाएगी, जो अपेक्षित व्यवहार है, इस बात का संकेत नहीं कि time पैरामीटर को नज़रअंदाज़ किया गया। यह न मानें कि दो अलग टाइमस्टैम्प पर एक जैसा नतीजा आने का मतलब है कि कुछ खराब है।
अनुरोध की लागत
एक रूपांतरण एक अनुरोध है। जो डैशबोर्ड एक साथ कई स्टोर किए गए रिकॉर्ड के समय बदलता है, उसे एक-एक टाइमस्टैम्प पर लूप चलाने के बजाय मूल निर्देशांकों को बल्क POST के ज़रिए बैच में भेजना चाहिए, जिससे प्रति आइटम एक अनुरोध की वही लागत रहती है, लेकिन एक ही कॉल में।
स्थानीय समय को सही रखना ज़्यादातर टीमों की उम्मीद से ज़्यादा मायने रखता है, जब तक कि कोई सपोर्ट टिकट गलत घंटा न दिखा दे। अनुरोध और रिस्पॉन्स फ़ील्ड का विवरण समय क्षेत्र लुकअप दस्तावेज़ में है।