संक्षेप में: Unix टाइमस्टैम्प 1 जनवरी 1970 की मध्यरात्रि UTC से बीते सेकंडों की संख्या है। लॉग और API इसे इसलिए उपयोग करते हैं क्योंकि यह असंदिग्ध और समय-क्षेत्र से स्वतंत्र है। दो चीज़ें उलझाती हैं: सेकंड को मिलीसेकंड से पहचानना, और यह याद रखना कि कच्चा नंबर हमेशा UTC में है जब तक आप उसे किसी स्थानीय क्षेत्र में न बदलें।
सर्वरों के बीच प्रविष्टियाँ तुलना करते समय, एक सादा पूर्णांक फ़ॉर्मैट की गई तारीख से तर्क करना आसान है: कोई समय-क्षेत्र नहीं, कोई लोकेल नहीं, डेलाइट-सेविंग की कोई अस्पष्टता नहीं। पर यही कच्चापन संदर्भ से अलग किसी टाइमस्टैम्प को ग़लत पढ़े जाने का कारण भी है।
टाइमस्टैम्प 1970 से क्यों शुरू होते हैं
Unix युग 1 जनवरी 1970 की मध्यरात्रि UTC है, जिसे बेल लैब्स के आरंभिक Unix डेवलपरों ने एक सरल, स्थिर संदर्भ-बिंदु के रूप में चुना। हर Unix टाइमस्टैम्प बस उस क्षण से बीते सेकंडों की गिनती है, जिससे अंकगणित — «इन दो घटनाओं के बीच कितना समय?» — एक सादा घटाव बन जाता है।
सेकंड या मिलीसेकंड?
लॉग पढ़ते समय यह सबसे आम ग़लती है। अंगूठे का नियम: यदि मान में 11 से अधिक अंक हैं (लगभग 10¹¹ से बड़ा), तो लगभग निश्चित रूप से मिलीसेकंड है। सेकंड में वर्तमान टाइमस्टैम्प लगभग 1.7 अरब (दस अंक) है; वही क्षण मिलीसेकंड में लगभग 1.7 खरब (तेरह अंक) है। मिलीसेकंड मान को सेकंड-आधारित पार्सर को दें, तो आप दसियों हज़ार वर्ष भविष्य में जा गिरेंगे।
टाइमस्टैम्प हमेशा UTC में है
Unix टाइमस्टैम्प एक निरपेक्ष क्षण को कोड करता है, स्थानीय घड़ी का समय को नहीं। इसे इंसान को दिखाने के लिए आप एक समय-क्षेत्र लागू करते हैं: वही नंबर «लंदन में 14:30» और «न्यूयॉर्क में 09:30» है। दोनों दिशाओं में साफ़ रूपांतरण का अर्थ है इच्छित क्षेत्र स्पष्ट करना: एक अच्छा कन्वर्टर मानक IANA समय-क्षेत्र डेटाबेस और Intl.DateTimeFormat API उपयोग करता है ताकि उस तारीख के लिए ऑफ़सेट (डेलाइट-सेविंग सहित) सही हो।
जो भी संग्रहीत या साझा करें, ISO 8601 में
जब टाइमस्टैम्प को मानव-पठनीय और साथ ही मशीन-सुरक्षित होना चाहिए, ISO 8601 उपयोग करें: 2024-03-15T14:30:00.000Z। T तारीख और समय को अलग करता है और Z UTC दर्शाता है। यह सादे टेक्स्ट के रूप में सही ढंग से क्रमबद्ध होता है और अगले पाठक के लिए सेकंड-बनाम-मिलीसेकंड का संदेह मिटा देता है।
2038 पर नोट
जो सिस्टम टाइमस्टैम्प को साइन-सहित 32-बिट पूर्णांक के रूप में संग्रहीत करते हैं, वे 19 जनवरी 2038 को ओवरफ़्लो हो जाते हैं। अधिकांश आधुनिक प्लेटफ़ॉर्म 64-बिट समय पर आ गए हैं, पर किसी पुराने सिस्टम या नियत-चौड़ाई डेटाबेस कॉलम से मिलने पर यह जानना उपयोगी है।
एक व्यावहारिक वर्कफ़्लो
- अपने लॉग या API प्रतिक्रिया से कच्चा मान कॉपी करें।
- इसे टाइमस्टैम्प कन्वर्टर में पेस्ट करें, जो सेकंड बनाम मिलीसेकंड स्वतः पहचानता है और चुने गए क्षेत्र में तारीख दिखाता है।
- घटाने से पहले जिन दो घटनाओं की तुलना कर रहे हैं उन्हें एक ही क्षेत्र में बदलें (या दोनों को UTC में रखें)।
- परिणाम को ISO 8601 के रूप में संग्रहीत या साझा करें ताकि अस्पष्टता फिर न आए। यदि आप किसी टिकट के लिए लॉग-अंश साफ़ कर रहे हैं तो इसे कैरेक्टर काउंटर के साथ जोड़ें।
बचने योग्य आम ग़लतियाँ
- एक ही तुलना में सेकंड और मिलीसेकंड मिलाना।
- यह मानना कि कच्चा टाइमस्टैम्प पहले से स्थानीय समय में है।
- भिन्न समय-क्षेत्रों में प्रस्तुत दो घटनाओं की तुलना करना।
- नियत-चौड़ाई 32-बिट समय-फ़ील्ड उपयोग करना जो 2038 नहीं झेल पाते।