Unix टाइम और Unix टाइमस्टैंप

Unix टाइम क्या है?

Unix टाइम (या ‘unixtime’) एक ऐसा सिस्टम है जो किसी तय संदर्भ क्षण से बीते सेकंड की संख्या गिनकर समय के किसी बिंदु को दर्शाता है। उस संदर्भ को Unix एपॉक (00:00:00 UTC, 1 जनवरी 1970) कहा जाता है।

Unix टाइमस्टैंप मूल रूप से मानों को साधारण संख्याओं के रूप में स्टोर करते हैं। कई कंप्यूटर सिस्टम और Linux मशीनें Unix टाइम को अपनी बुनियादी समय-गणना पद्धति के रूप में अपनाते हैं।

आप असल दुनिया में यही विचार अलग-अलग नामों से देखेंगे — Unix टाइमस्टैंप, एपॉक टाइम, POSIX टाइम, या बस “Unix स्टैंप”। ये सब एक ही मान की ओर इशारा करते हैं: Unix एपॉक के बाद बीते सेकंड की संख्या। “Unix टाइम” आम तौर पर सिस्टम को ही बताता है, जबकि “Unix टाइमस्टैंप” से आम तौर पर कोई एक स्टोर किया गया संख्यात्मक मान समझा जाता है, लेकिन व्यवहार में ये दोनों शब्द एक-दूसरे की जगह इस्तेमाल होते हैं।

Unix टाइम की उत्पत्ति

Unix टाइम या unixtime का विचार शुरुआती Linux और Unix ऑपरेटिंग सिस्टम से आया था, और इसे एक संक्षिप्त तथा एकरूप समय फ़ॉर्मैट के तौर पर सोचा गया था। कई Linux-आधारित वातावरण में इसे POSIX टाइम भी कहा जाता है।

अलग-अलग सिस्टम ने Unix टाइम को अपनाया है, जहां इसका उपयोग समय के डेटा के लिए एक एकीकृत डेटा फ़ॉर्मैट के रूप में होता है। Unix एपॉक के तौर पर 1 जनवरी 1970 को चुनना मनमाना था, लेकिन इससे सिस्टम के बीच सिंक्रोनाइज़ेशन के लिए एक ठोस आधार मिला।

POSIX टाइम और ‘date’ कमांड

Linux, macOS और दूसरे Unix-जैसे सिस्टम में ऑपरेटिंग सिस्टम का कर्नेल समय को अंदरूनी तौर पर Unix टाइमस्टैंप के रूप में रखता है। POSIX टाइम उसी अवधारणा को बताता है — यह नाम बस IEEE Std 1003.1 स्पेसिफ़िकेशन को दर्शाता है, जिसने Unix-जैसे वातावरण में इस व्यवहार को औपचारिक रूप दिया। रोज़मर्रा के उपयोग में POSIX टाइम और Unix टाइम एक ही संख्या हैं।

शेल उस संख्या को date यूटिलिटी के ज़रिए उपलब्ध कराता है। ‘date +%s’ चलाने पर मौजूदा Unix टाइमस्टैंप सेकंड में प्रिंट होता है, और ‘date -d @1700000000‘ किसी स्टोर किए गए मान को वापस पढ़ने लायक लोकल तारीख में बदल देता है। macOS पर इसका समतुल्य ‘date -r 1700000000’ है। इन एक-पंक्ति कमांड की वजह से ही Unix टाइम शेल स्क्रिप्ट, cron जॉब और लॉग रोटेशन टूल की व्यावहारिक भाषा है।

Unix टाइम की गणना कैसे करें

Unix टाइम की गणना करने के लिए आप UTC में Unix एपॉक के बाद बीते गैर-लीप सेकंड की संख्या गिनते हैं और लीप वर्ष तथा लीप सेकंड को इसमें शामिल नहीं करते। उदाहरण के लिए, 1 जनवरी 1970 के बाद की किसी भी तारीख या तारीखों के लिए आप एपॉक को घटाते हैं और अंतर को सेकंड में बदल लेते हैं।

टाइम ज़ोन के साथ काम करते समय आप गणना से पहले लोकल समय को UTC में बदल लेते हैं। चूंकि Unix टाइम लीप सेकंड को नज़रअंदाज़ करता है, हर दिन को ठीक 86,400 सेकंड माना जाता है — यानी जब लीप सेकंड जोड़े जाते हैं, तब यह असली परमाणु/UTC समय से अलग हो सकता है।

Unix टाइम में ज़्यादातर दिन ठीक 86,400 सेकंड के रूप में गिने जाते हैं। इसका मतलब है कि एक दिन जोड़ने पर टाइमस्टैंप आम तौर पर 86,400 बढ़ जाता है (लीप सेकंड वाले दिन ही इसका एकमात्र अपवाद हैं)।

JavaScript में हम Date.now() को कॉल करके मौजूदा Unix मान पा सकते हैं (जो एपॉक के बाद के मिलीसेकंड देता है), और फिर 1000 से भाग देकर सेकंड में Unix स्टैंप पा सकते हैं।

Unix टाइमस्टैंप का फ़ॉर्मैट और उदाहरण

एक मानक Unix टाइमस्टैंप 10 अंकों का पूर्णांक होता है, जिसे सेकंड में मापा जाता है। उदाहरण के लिए, 1700000000 का मतलब 14 नवंबर 2023, 22:13:20 UTC है। तीन अंक और जोड़ दें तो मिलीसेकंड मिल जाते हैं (13 अंक), और JavaScript तथा कई वेब API डिफ़ॉल्ट रूप से यही लौटाते हैं।

यह फ़ॉर्मैट सिर्फ़ एक गिनती है — इसमें कोई विभाजक नहीं, कोई टाइम ज़ोन टैग नहीं, कोई कैलेंडर मेटाडेटा नहीं। सब कुछ संख्या में ही एनकोड होता है। कुछ संदर्भ बिंदुओं से इस पैमाने को पढ़ना आसान हो जाता है:

एपॉक से पहले की तारीखें पूरी तरह मान्य हैं, उन पर बस ऋण चिह्न लगता है। मान -14182940 ठीक उसी क्षण पर पड़ता है जब Apollo 11 चंद्रमा पर उतरा था। तालिका की आख़िरी पंक्ति साइन्ड 32-बिट Unix टाइमस्टैंप की ऊपरी सीमा बताती है, और यहीं से वर्ष 2038 की समस्या शुरू होती है।

कोड में Unix टाइमस्टैंप प्राप्त करना

हर मुख्यधारा की भाषा Unix टाइम को एक-पंक्ति कमांड के ज़रिए उपलब्ध कराती है। इनसे मिलने वाले मान एक जैसे होते हैं, क्योंकि टाइमस्टैंप परिभाषा के हिसाब से टाइम ज़ोन से स्वतंत्र होता है।

• JavaScript: सेकंड के लिए Math.floor(Date.now() / 1000), या मिलीसेकंड के लिए Date.now()।
• Python: पूरे सेकंड के लिए import time; int(time.time()); सेकंड से छोटी परिशुद्धता बनाए रखनी हो तो int() हटा दें।
• Bash / Linux: date +%s सीधे टर्मिनल में मौजूदा Unix टाइमस्टैंप प्रिंट करता है।
• PHP: सेकंड के लिए time(), भिन्नात्मक परिशुद्धता के लिए microtime(true)।
• Java: सेकंड के लिए System.currentTimeMillis() / 1000L।
• Go: time.Now().Unix()।
• SQL: MySQL में UNIX_TIMESTAMP(), PostgreSQL में EXTRACT(EPOCH FROM NOW())।

दूसरी दिशा में बदलना — यानी किसी स्टोर किए गए टाइमस्टैंप से वापस इंसान के पढ़ने लायक तारीख में — उतना ही पहले से मौजूद है। Python में यह datetime.utcfromtimestamp(ts) है; JavaScript में new Date(ts * 1000).toISOString()। दिखाते समय लक्षित टाइम ज़ोन हमेशा साफ़-साफ़ बताएं, क्योंकि टाइमस्टैंप खुद कोई ज़ोन जानकारी नहीं रखता।

सेकंड, मिलीसेकंड और उससे ज़्यादा बारीक परिशुद्धता

मूल Unix टाइमस्टैंप पूरे सेकंड गिनता है, लेकिन आधुनिक सिस्टम को अक्सर इससे बारीक रेज़ॉल्यूशन की ज़रूरत होती है। यह चलन अंकों की गिनती से आसानी से पहचाना जा सकता है: 10 अंक यानी सेकंड, 13 अंक यानी मिलीसेकंड, 16 अंक यानी माइक्रोसेकंड और 19 अंक यानी नैनोसेकंड।

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

Unix टाइम के आम उपयोग

Unix टाइम का उपयोग आम तौर पर डेटाबेस, लॉग, API और फ़ाइल फ़ॉर्मैट में टाइमस्टैंप स्टोर करने के लिए होता है। इस समय फ़ॉर्मैट का उपयोग करके सिस्टम समय के मानों को एक जैसे तरीके से स्टोर करते हैं।

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

वर्ष 2038 की समस्या

Unix टाइम का एक मशहूर एज केस है। जो सिस्टम इस मान को साइन्ड 32-बिट पूर्णांक में स्टोर करते हैं, वे सिर्फ़ 2,147,483,647 सेकंड तक ही गिन सकते हैं, और यह सीमा 03:14:07 UTC, 19 जनवरी 2038 को पूरी हो जाती है। इसके बाद की अगली गिनती संख्या को ऋणात्मक दायरे में पलट देती है और तारीख वापस 1901 में चली जाती है। इसे कभी-कभी Y2038 या Unix मिलेनियम बग भी कहा जाता है।

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

अक्सर पूछे जाने वाले सवाल

Unix टाइमस्टैंप में कितने अंक होते हैं?

सेकंड के लिए दस अंक (साल 2286 तक), मिलीसेकंड के लिए तेरह। इससे अलग लंबाई वाले टाइमस्टैंप में लगभग हमेशा परिशुद्धता का मेल नहीं बैठता, और पार्स करने से पहले उसकी जांच कर लेनी चाहिए।

क्या Unix टाइम और UTC एक ही हैं?

ठीक वैसा नहीं। Unix टाइम किसी तय UTC क्षण से सेकंड गिनता है, इसलिए परिभाषा के हिसाब से यह UTC पर ही टिका है, लेकिन यह लीप सेकंड को उस तरह दर्ज नहीं करता जैसे असली UTC करता है। ज़्यादातर एप्लिकेशन के लिए यह अंतर दिखता ही नहीं; उच्च परिशुद्धता वाली समय-गणना के लिए दिखता है।

क्या Unix टाइमस्टैंप ऋणात्मक हो सकता है?

हां। ऋणात्मक मान 1 जनवरी 1970 से पहले की तारीखों को दर्शाते हैं। गणित सही है, फिर भी हर लाइब्रेरी इन्हें ठीक से हैंडल नहीं करती — उन पर भरोसा करने से पहले जांच लें।

Unix टाइम और एपॉक टाइम में क्या अंतर है?

रोज़मर्रा के उपयोग में कोई अंतर नहीं। दोनों शब्द 1 जनवरी 1970 UTC के बाद के सेकंड को बताते हैं। “एपॉक टाइम” थोड़ा ज़्यादा सामान्य शब्द है, क्योंकि दूसरे सिस्टम अपने-अपने एपॉक तय करते हैं (.NET एपॉक, Mac OS एपॉक वगैरह), लेकिन 99% संदर्भों में लोगों का मतलब Unix टाइम ही होता है।