Unix timestamp बदलें

Unix timestamp 1 जनवरी 1970 UTC से गिनती करता है। सेकंड में आज की तारीख़ें दस अंकों की होती हैं; मिलीसेकंड में तेरह की। आकार का यही फ़र्क़ बिना पूछे इकाई तय करने देता है, और यह दहलीज़ किसी भी ऐसी तारीख़ से बहुत दूर है जिसे कोई देखने वाला हो।

यह अंदाज़ा हमेशा बताया जाता है, क्योंकि इस बदलाव की चिरपरिचित ग़लती चुपचाप सही निकल आना है। मिलीसेकंड वाले नंबर को सेकंड की तरह पढ़ने पर तारीख़ साल 55,000 में जाती है और पकड़ में आ जाती है; उलटा करने पर 1970 आता है और वह भी पकड़ में आ जाता है। जो पकड़ में नहीं आता वह वह औज़ार है जो ख़ुद तय कर ले और बताए नहीं।

नंबर अपने साथ समय-क्षेत्र नहीं ले जाता: वह एक निरपेक्ष क्षण है। समय-क्षेत्र तभी आता है जब उसे तारीख़ की तरह लिखा जाए, और यहीं से इस बदलाव की सबसे महँगी ग़लतफ़हमी निकलती है — दो लोग एक ही timestamp देखकर अलग-अलग दिन पढ़ रहे हों क्योंकि वे अलग-अलग क्षेत्रों में हैं।

इसलिए दोनों निकलते हैं। भारत UTC से साढ़े पाँच घंटे आगे है, इसलिए 18:30 UTC के बाद का कोई भी क्षण भारत में अगले दिन का हो चुका होता है। जब किसी लॉग की तुलना किसी डैशबोर्ड से की जाती है तो आधी असहमतियाँ ठीक यही होती हैं।

IST का अंतर पूरे घंटों में नहीं है, +05:30 है, और यह उन तंत्रों को तोड़ता है जो मान लेते हैं कि offset पूर्णांक घंटों में होते हैं। यह मान्यता पुराने बाइनरी फ़ॉर्मैट में, कुछ रिपोर्टिंग औज़ारों में और हाथ से लिखे उन रूपांतरणों में मिलती है जहाँ किसी ने घंटा जोड़-घटा दिया और मिनट भूल गया — और नतीजा तीस मिनट खिसका हुआ होता है, जो इतना छोटा है कि हफ़्तों तक किसी को खटकता नहीं।

दूसरी तरफ़ भारत में डेलाइट सेविंग नहीं है — आख़िरी बार वह युद्ध के वर्षों में लागू हुई थी — इसलिए वह दोहरा पड़ने वाला घंटा और वह ग़ायब घंटा, जो यूरोप और अमेरिका की रिपोर्टों को साल में दो बार बिगाड़ते हैं, यहाँ होते ही नहीं। स्थानीय समय में रखा भारतीय डेटा इस एक मामले में यूरोप के डेटा से ज़्यादा सुरक्षित है; UTC में रखना तब भी बेहतर रहता है, क्योंकि दूसरे क्षेत्रों का डेटा उसी तालिका में आ ही जाता है।

`Asia/Kolkata` एक नियम-समूह है और `+05:30` एक संख्या। दोनों आज एक ही उत्तर देते हैं, पर वे एक चीज़ नहीं हैं: नाम अपने साथ इतिहास लेकर चलता है और भविष्य में बदल भी सकता है, जबकि संख्या सिर्फ़ इस क्षण के लिए सही है। जो तंत्र भविष्य की तारीख़ें रखते हैं उन्हें नाम रखना चाहिए, संख्या नहीं।

भारतीय डेटा में इसका एक अपना कोना है: IANA के डेटाबेस में यह क्षेत्र लंबे समय तक `Asia/Calcutta` कहलाता था और वह नाम आज भी उपनाम के रूप में चलता है। दोनों नाम एक ही नियम बताते हैं, पर दो तंत्रों की स्ट्रिंग-तुलना उन्हें अलग मानती है — और यह उन विसंगतियों में है जिन्हें ढूँढ़ने में सबसे ज़्यादा समय लगता है।

32 बिट के चिह्न-सहित पूर्णांक में रखा timestamp 19 जनवरी 2038 को छलक जाता है और 1901 पर कूद जाता है। यह दूर लगता है और अब नहीं है: बीस साल आगे देखने वाली कोई भी गणना — कोई होम लोन, कोई प्रमाणपत्र, कोई परिशोधन-तालिका — आज ही उस सीमा को पार करती है।

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

`2023-11-14T22:13:20Z` वाला रूप इसलिए बना है कि उसे टेक्स्ट की तरह क्रम में लगाने पर वह तारीख़ के हिसाब से भी क्रम में लग जाए। इसीलिए यही रूप फ़ाइल के नामों में, कुंजियों में और हर उस जगह ठीक रहता है जहाँ कोई चीज़ वर्णक्रम में लगाने वाली है, बिना यह जाने कि वह तारीख़ें देख रही है।

आख़िर का `Z` UTC बताता है। उसका न होना ग़लतियों का न ख़त्म होने वाला स्रोत है: बिना क्षेत्र वाली स्ट्रिंग को हर तंत्र अपनी धारणा से पढ़ता है, और दो सेवाएँ एक ही टेक्स्ट को घंटों दूर के दो क्षणों की तरह ले सकती हैं। भारतीय डेटा में यह और ज़्यादा चुभता है, क्योंकि भूला हुआ अंतर साढ़े पाँच घंटे का होता है और वह आधा घंटा किसी गोल संख्या जैसा नहीं दिखता। तारीख़ लिखनी है तो क्षेत्र भी लिखिए।

Unix समय यह मानकर चलता है कि हर दिन में ठीक 86,400 सेकंड होते हैं, जो सच नहीं है: पृथ्वी के अनियमित घूर्णन की भरपाई के लिए 1972 से अब तक सत्ताईस leap second जोड़े जा चुके हैं। यह फ़ॉर्मैट उन्हें बस अनदेखा कर देता है।

लगभग सबके लिए यही सही फ़ैसला है, क्योंकि इससे तारीख़ों का गणित काम करता रहता है। यह खगोल विज्ञान में, नौवहन-तंत्रों में और कुछ वैज्ञानिक मापों में सही रहना बंद कर देता है, जहाँ वे सचमुच मायने रखते हैं — और वहाँ Unix समय इस्तेमाल भी नहीं होता, बल्कि ऐसे पैमाने इस्तेमाल होते हैं जो उन्हें गिनते हैं।

ISO की सप्ताह-गिनती सप्ताह 1 को वह सप्ताह मानती है जिसमें साल का पहला बृहस्पतिवार पड़ता है, और सप्ताह सोमवार से शुरू होते हैं। इससे यह निकलता है कि 1 जनवरी पिछले साल के सप्ताह 52 में पड़ सकती है, और 31 दिसंबर अगले साल का सप्ताह 1 हो सकती है।

यह ब्योरा हर जनवरी में साप्ताहिक रिपोर्टें तोड़ता है। व्यावहारिक नियम यह है कि सप्ताह का साल हमेशा तारीख़ का साल नहीं होता, और जो सप्ताह के हिसाब से समूह बनाता है उसे दोनों साथ रखने होंगे — बिना साल के «सप्ताह 1» ठीक उन्हीं तारीख़ों पर दुविधा भरा है जिन पर सबसे ज़्यादा देखा जाता है।

सापेक्ष समय वाली पंक्ति — «तीन साल पहले», «ग्यारह मिनट पहले» — परिशुद्धता नहीं देती, पैमाना देती है। एक नज़र में यही बताती है कि लॉग आज सुबह का है या पिछले महीने की तैनाती का, और timestamp देखने के पीछे असल सवाल आम तौर पर यही होता है।

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

Timestamp लगभग कभी अकेला सफ़र नहीं करता: वह किसी लॉग पंक्ति से, किसी डेटाबेस पंक्ति से या किसी payload से कॉपी होता है जिसके बग़ल में कोई उपयोक्ता-पहचान पड़ी होती है। चूँकि बदलाव पन्ने पर ही होता है, न वह नंबर आपके डिवाइस से निकलता है और न उसके साथ आई हुई कोई चीज़।

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