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