Unix टाइम (Unix timestamp) 1 जनवरी 1970, 00:00:00 UTC से गुज़रे सेकंड की गिनती है। इस तारीख़ को "Unix epoch" कहा जाता है, और लगभग हर मॉडर्न ऑपरेटिंग सिस्टम, डेटाबेस और प्रोग्रामिंग लैंग्वेज इसी से समय गिनते हैं।
ठीक 1970 ही क्यों
यह तारीख़ किसी ख़ास घटना की वजह से नहीं चुनी गई, बल्कि पूरी तरह प्रैक्टिकल वजह से: 1970 के दशक की शुरुआत में Bell Labs के Unix डेवलपर्स ने बस उस समय के मौजूदा साल को एक सुविधाजनक, गोल शुरुआती पॉइंट मान लिया। इस तारीख़ के पीछे कोई गहरा मतलब नहीं है।
UPI और पेमेंट लॉग में यह फ़ॉर्मैट क्यों हावी है
भारत के तेज़ी से बढ़ते डिजिटल पेमेंट इकोसिस्टम में — जहाँ हर सेकंड लाखों ट्रांज़ैक्शन प्रोसेस होते हैं — बैकएंड सिस्टम अक्सर हर इवेंट को Unix टाइमस्टैम्प के तौर पर लॉग करते हैं, क्योंकि इससे इवेंट्स को टाइम ज़ोन की उलझन के बिना सही क्रम में सॉर्ट और तुलना करना आसान हो जाता है, चाहे सर्वर देश में कहीं भी हो।
साल 2038 की समस्या
कई पुराने सिस्टम Unix टाइम को 32-बिट साइन्ड इंटीजर के तौर पर स्टोर करते हैं, जो सिर्फ़ 19 जनवरी 2038 तक की वैल्यू दर्शा सकता है। उस तारीख़ के बाद, ऐसा नंबर ओवरफ़्लो हो जाएगा — यह सिर्फ़ थ्योरी नहीं है, क्योंकि सस्ते एम्बेडेड डिवाइस और पुराने इंडस्ट्रियल कंट्रोलर अक्सर दशकों तक बिना अपडेट के चलते रहते हैं।
यह किस काम आता है
- लॉग या API रिस्पॉन्स से मिले टाइमस्टैम्प को समझने लायक़ तारीख़ और समय में बदलना।
- बिना कैलेंडर का मैनुअल हिसाब लगाए दो पलों के बीच का फ़र्क़ निकालना।
- टाइमस्टैम्प के साथ काम करते वक़्त टाइम ज़ोन से जुड़ी समस्याओं को डायग्नोज़ करना।
Unix-टाइम और लीप सेकंड
Unix टाइम मान लेता है कि हर दिन ठीक 86400 सेकंड का होता है, और लीप सेकंड (leap seconds) को नज़रअंदाज़ करता है, जिन्हें समय-समय पर UTC में जोड़ा जाता है ताकि पृथ्वी के घूमने की गति में आई सुस्ती की भरपाई हो सके। इसका मतलब है कि Unix टाइम, लीप सेकंड जोड़े जाने के पलों में तकनीकी रूप से UTC का सटीक प्रतिबिंब नहीं होता — ज़्यादातर सिस्टम काउंटर में आने वाली रुकावट से बचने के लिए बस एक सेकंड को "फैला" देते हैं या दोहरा देते हैं।