यूनिक्स टाइमस्टैम्प कन्वर्टर

अंक गिनना

टाइमस्टैम्प पढ़ने में सचमुच पेचीदा बस एक ही बात है — उसकी इकाई पहचानना, और परिमाण से वह तय हो जाती है। व्यवहार में कोई दुविधा नहीं, क्योंकि जिन तारीख़ों पर असल में कोई काम करता है, उनके लिए ये परास आपस में नहीं टकरातीं।

ग़लती हो जाए तो हज़ार गुना का फ़र्क़ पड़ता है, और नतीजा या तो 1970 के शुरुआती सालों में जा गिरता है या हज़ारों साल आगे। सामने रखकर देखें तो ज़ाहिर; और जब वह लॉग टेबल का बस एक स्तंभ हो तो पूरी तरह अदृश्य — और असल में वह वहीं काटता है।

Unix समय दरअसल गिनता क्या है

1 जनवरी 1970 को 00:00:00 UTC से अब तक के सेकंड, यह मानकर कि हर दिन ठीक 86,400 सेकंड का है।

यह मान्यता झूठी है। परमाणु समय को पृथ्वी के घूर्णन से — जो धीरे-धीरे मंद पड़ रहा है — मिलाए रखने के लिए हर कुछ साल में लीप सेकंड जोड़े जाते हैं। Unix समय उन्हें दर्शाता नहीं — सिस्टम या तो एक सेकंड दोहरा देते हैं या उसे पूरे दिन में फैला देते हैं, ताकि गिनती एकसार बनी रहे।

नतीजा यह कि Unix समय 1970 से बीते सेकंडों की सच्ची गिनती नहीं है; वह क़रीब सत्ताईस सेकंड पीछे है। शेड्यूलिंग, लॉगिंग और मियाद के लिए यही सही सौदा है, क्योंकि वहाँ खगोलीय शुद्धता से ज़्यादा एकसार गणित मायने रखता है। पर जहाँ सचमुच बीता हुआ समय नापना हो, वहाँ मोनोटोनिक घड़ी इस्तेमाल कीजिए — दीवार-घड़ी वाला समय NTP के सुधार पर पीछे भी कूद सकता है।

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

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

आधुनिक हर चीज़ 64 बिट इस्तेमाल करती है और क़रीब 292 अरब साल तक ठीक है। जो आधुनिक नहीं है: एम्बेडेड फ़र्मवेयर, औद्योगिक नियंत्रक, डेटाबेस के कुछ पुराने कॉलम प्रकार, और वह C कोड जो अब भी time_t को 32-बिट मानता है। सबसे ज़्यादा ख़तरे में वही सिस्टम हैं जिन्हें कोई देख नहीं रहा — Y2K को महँगा भी इसी बात ने बनाया था।

असल में कौन-सा फ़ॉर्मैट इस्तेमाल कीजिए

UTC में ISO 8601 — हर उस चीज़ के लिए जो सिस्टमों की सीमा पार करती है या किसी इंसान द्वारा पढ़ी जाती है:

2026-08-27T14:30:00Z

यह असंदिग्ध है, सादी स्ट्रिंग के रूप में भी सही क्रम में लगता है, और रात दो बजे लॉग में भी पढ़ा जाता है। Z मायने रखता है: उसके बिना ज़्यादातर पार्सर उसे स्थानीय समय मान लेते हैं, और आपने ऐसा बग गढ़ लिया जो सिर्फ़ दूसरे देशों के उपयोगकर्ताओं पर उभरता है।

Unix सेकंड भीतरी इस्तेमाल के लिए ठीक हैं — JWT के exp और iat क्लेम यही इस्तेमाल करते हैं, और पूर्णांक की तुलना सस्ती है। क़ीमत यह है कि वे पढ़े नहीं जाते और ऊपर बताए इकाई-भ्रम को न्योता देते हैं।

बचने लायक़: ऐसा हर फ़ॉर्मैट जिसमें ऑफ़सेट हो पर ज़ोन का नाम न हो (+01:00 यह नहीं बताता कि वह BST है या CET, और आने वाली तारीख़ों के लिए यह मायने रखता है), और 03/04/2026 वाले इलाक़े की हर चीज़, जिसका मतलब अटलांटिक के किस किनारे पढ़ रहे हैं इसके हिसाब से दो अलग दिन होता है।

भविष्य की घटनाएँ सहेजना

एक बारीकी जो लोगों को फँसा देती है। अगले मार्च की सुबह नौ बजे की किसी बैठक के लिए UTC सहेजना ग़लत है — अगर अब और तब के बीच टाइमज़ोन के नियम बदल गए, और सरकारें बदलती ही हैं, तो बैठक खिसक जाएगी। भविष्य की स्थानीय घटनाओं को स्थानीय समय और ज़ोन के नाम (Europe/London) के साथ सहेजना चाहिए, और दिखाते वक़्त तब के प्रचलित नियमों से बदलना चाहिए। बीती घटनाओं में उलटा है: UTC, क्योंकि जो हो चुका वह तय है।

संबंधित

JWT के exp और iat क्लेम Unix सेकंड हैं — JWT डिकोडर उन्हें आपके लिए बदल देता है और मियाद ख़त्म होने पर निशान लगा देता है। और अगर आपको बदलना नहीं, शेड्यूल करना है, तो cron पार्सर बताता है कि कोई शेड्यूल अगली बार कब चलेगा।