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

एपॉक सेकंड = 1970-01-01 से बीते पूरे दिन × 86400 + UTC में आधी रात से बीते सेकंड; तारीख़ और समय = वही हिसाब उलटी दिशा में

दिशा

किस तरफ़ जाना है: टाइमस्टैम्प डालकर तारीख़ लेनी है, या तारीख़ और समय डालकर टाइमस्टैम्प लेना है

टाइमस्टैम्प

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

इकाई

आपकी डाली गिनती सेकंड गिनती है (इस सदी की तारीख़ों के लिए दस अंक) या मिलीसेकंड (तेरह अंक)। यह भी सिर्फ़ टाइमस्टैम्प से तारीख़ वाली दिशा में लगती है

तारीख़

UTC की कैलेंडर तारीख़, YYYY-MM-DD के रूप में। सिर्फ़ तारीख़ से टाइमस्टैम्प वाली दिशा में इस्तेमाल होती है

समय

UTC की घड़ी का समय, HH:MM या HH:MM:SS के रूप में। यह भी सिर्फ़ तारीख़ से टाइमस्टैम्प वाली दिशा में लगता है

तारीख़ (UTC)

जिस कैलेंडर तारीख़ पर वह टाइमस्टैम्प पड़ता है, UTC में। यही इस पेज का मुख्य नतीजा है

समय (UTC)

UTC की घड़ी का समय, हमेशा सेकंड के साथ। इनपुट में सेकंड का कोई अंश हो तो वह गोल नहीं किया जाता, हटा दिया जाता है

दिन (UTC)

उस तारीख़ पर पड़ने वाला दिन, और पैनल इसे नाम से छापता है — रविवार, सोमवार, मंगलवार, बुधवार, गुरुवार, शुक्रवार या शनिवार

ISO 8601

पूरा ISO 8601 रूप, जैसे 2026-01-15T12:00:00Z — कोड या लॉग में चिपकाने के लिए तैयार

टाइमस्टैम्प

वही पल, 1970-01-01T00:00:00Z से बीते पूरे सेकंडों में; गोल नहीं किया जाता बल्कि काटा जाता है, ताकि यह ऊपर छपे घड़ी के समय से कभी न टकराए

टाइमस्टैम्प (मिलीसेकंड)

वही पल मिलीसेकंड में — सेकंड वाला मान गुणा हज़ार, और इनपुट में आया सेकंड का अंश भी साथ रखा हुआ

इसका इस्तेमाल तब कीजिए जब किसी संख्या को किसी तारीख़ से मिलाना हो: सर्वर लॉग, API का जवाब या डेटाबेस की कोई पंक्ति पढ़ते वक़्त; यह जाँचते वक़्त कि आपको भेजा गया मान सेकंड में है या मिलीसेकंड में; या भंडारण के लिए कोई टाइमस्टैम्प बनाते वक़्त। पेज जानबूझकर UTC पर ही रुकता है। यह आपके स्थानीय समय में नहीं बदलता और यह नहीं पूछता कि आप किस क्षेत्र में हैं — यूनिक्स टाइमस्टैम्प का कोई क्षेत्र होता ही नहीं, इसलिए ईमानदार जवाब UTC वाला है, और उसे स्थानीय घड़ी पर पढ़ना समय क्षेत्र कैलकुलेटर का काम है। यह टाइमस्टैम्प पर हिसाब भी नहीं करता: «इसमें तीस दिन जोड़ने पर क्या आएगा», इसके लिए पहले बदलिए और फिर तारीख़ वाला कैलकुलेटर लीजिए।

1. 1768478400 — संदर्भ वाला पल

   1. गिनती सेकंड में है, यानी वह पहले से एपॉक मान है — पढ़ने से पहले कोई बदलाव नहीं चाहिए
   2. इसे 86400 से भाग देने पर 1 जनवरी 1970 से बीते पूरे दिन मिलते हैं, और शेष से दिन का समय: नतीजा 15 जनवरी 2026, 12:00:00 UTC पर आता है
   3. 15 जनवरी 2026 गुरुवार है, इसलिए दिन का नाम गुरुवार छपता है
   4. पूरा लिखने पर वह 2026-01-15T12:00:00Z बनता है — वही रूप जिसकी उम्मीद कोई लॉग या API रखता है
   5. मिलीसेकंड वाली पंक्ति वही पल गुणा हज़ार है, यानी जब कोई सिस्टम इसे मिलीसेकंड में बताता है तो वही मान ऐसा दिखता है

   यही वह मान है जिस पर पेज खुलता है, और इसे लंगर की तरह याद रख लेना काम आता है: 1768478400 यानी 15 जनवरी 2026 की दोपहर UTC। एक टाइमस्टैम्प परिचित हो जाने के बाद बाक़ी हर बदलाव जाँचना आसान रहता है, क्योंकि ग़लत जवाब आम तौर पर या तो पूरे दिनों से ग़लत होता है या हज़ार गुना से, और दोनों जाने-पहचाने लंगर के सामने तुरंत पकड़ में आ जाते हैं। एक बात शुरू में ही देख लीजिए: इनपुट के बॉक्स में गिनती बिना विराम के लिखी जाती है, वही मान नतीजे की पंक्ति में भारतीय अंक-समूहन में दिखता है, और नीचे की तालिका में फिर बिना समूहन के — तीनों एक ही संख्या हैं, लिखने का ढंग अलग है।

2. 2147483647 — 32 बिट युग का आख़िरी सेकंड

   1. यह मान दो की इकतीसवीं घात में से एक घटाकर बनता है: 32 बिट के चिह्नित पूर्णांक में जो सबसे बड़ी संख्या रखी जा सकती है
   2. एपॉक गिनती की तरह पढ़ने पर यह 19 जनवरी 2038, 03:14:07 UTC बनता है — और 2038 समस्या इसी की है: जो सिस्टम टाइमस्टैम्प उस प्रकार में रखते हैं, उनके पास एक सेकंड बाद जगह ख़त्म हो जाती है और गिनती 1901 की किसी तारीख़ पर लुढ़क जाती है
   3. 19 जनवरी 2038 मंगलवार है, इसलिए दिन का नाम मंगलवार छपता है
   4. सेकंड वाली पंक्ति वही मान लौटा देती है, और यही वह जाँच है कि मान उसी हिसाब से अंदर गया और बाहर आया

   यह नीचे की संदर्भ तालिका की वही पंक्ति है, जिसे कैलकुलेटर से गुज़ारा गया है। 2038 समस्या की बात यह नहीं है कि वह तारीख़ पहुँच से बाहर है — यह पेज उसे बिना शिकायत बदल देता है — बात यह है कि 32 बिट के चिह्नित काउंटर वाला कोई प्रोग्राम अगला सेकंड रख ही नहीं सकता। 64 बिट के काउंटरों पर ऐसी कोई सीमा उस दायरे में आती ही नहीं जितना मायने रखता है, इसीलिए वही मान मिलीसेकंड में निश्चिंत होकर लिखा जा सकता है।

3. अंश वाला मिलीसेकंड मान: 1768478400500

   1. गिनती में तेरह अंक हैं और इकाई मिलीसेकंड कहती है, इसलिए यह पहले उदाहरण वाला ही पल है, बस आधा सेकंड आगे
   2. घड़ी का समय अंश को गोल नहीं करता बल्कि हटा देता है, इसलिए वह 12:00:00 पढ़ता है, 12:00:01 नहीं
   3. सेकंड वाली पंक्ति भी उसी से मिलती है: उसमें भी अंश नहीं जाता
   4. मिलीसेकंड वाली पंक्ति अंश साथ रखती है, क्योंकि नतीजे में उसका अकेला ठिकाना वही है

   यही वह एक मामला है जहाँ गोल करना और काटना आपस में टकराते, और यही वजह है कि सेकंड वाली पंक्ति काटती है। आधे सेकंड को ऊपर गोल करने पर वह ठीक ऊपर छपे घड़ी के समय से एक सेकंड बड़ी संख्या छापती, और दोनों पंक्तियाँ मिलाकर देखने वाला पाठक यही नतीजा निकालता कि इनमें से एक टूटी हुई है। हर पंक्ति का दिखाए गए समय से मेल खाना सबसे नज़दीकी पूर्णांक से ज़्यादा मायने रखता है।

4. दूसरी दिशा: 15 जनवरी 2026, 12:00:30 UTC

   1. तारीख़ को 1 जनवरी 1970 से बीते दिनों की गिनती में बदला जाता है और आधी रात तक के सेकंड निकालने के लिए 86400 से गुणा किया जाता है
   2. उसमें आधी रात से बीते तीस सेकंड जोड़े जाते हैं: कुल बनता है पहले उदाहरण का मान जमा तीस
   3. समय वाला बॉक्स सेकंड लेता है, इसलिए 12:00:30 ठीक-ठीक पढ़ा जाता है, मिनट तक काटा नहीं जाता
   4. तारीख़ और दिन वाली पंक्तियाँ बदले बिना लौटती हैं, क्योंकि बाहर जाकर वापस आना वही मान होता है

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

पेज जो कुछ भी बताता है वह UTC में है और वह कभी स्थानीय समय क्षेत्र में नहीं बदलता — यूनिक्स टाइमस्टैम्प की परिभाषा में ही क्षेत्र नहीं होता, इसलिए उसे स्थानीय घड़ी पर पढ़ने वाला पेज समय क्षेत्र कैलकुलेटर है। दायरा 1970-01-01T00:00:00Z से 2100-12-31T23:59:59Z तक है, और इसके बाहर के मान चुपचाप हिसाब करने के बजाय ठुकरा दिए जाते हैं: ऋणात्मक टाइमस्टैम्प एपॉक से पहले की तारीख़ों के लिए वैध हैं, पर पेज यह बताकर रुक जाता है, अपने ही बताए दायरे से टकराता 1969 का जवाब लौटाने के बजाय। सेकंड का अंश गोल नहीं किया जाता, काटा जाता है, इसलिए मिलीसेकंड वाला मान अपनी सटीकता खोता नहीं और दिखने वाले सेकंड पर असर भी नहीं डालता। UTC में लीप सेकंड जोड़े जाते हैं, पर एपॉक सेकंड की परिभाषा उन्हें नहीं गिनती, और यह पेज भी नहीं गिनता — इसीलिए वह किसी दिन को 86401 सेकंड का नहीं मानता। पेज और किसी रूप में लिखी तारीख़ नहीं पढ़ता, आपकी मशीन का टाइमस्टैम्प नहीं लेता, और हिसाब नहीं करता — बदले हुए मान से तीस दिन आगे की तारीख़ के लिए तारीख़ वाला कैलकुलेटर लीजिए।

एपॉक समय क्या है?

एपॉक समय यानी 1970-01-01T00:00:00 UTC से अब तक बीते सेकंडों की गिनती, और यही वह शून्य बिंदु है जहाँ से यूनिक्स सिस्टम गिनना शुरू करते हैं। इसे यूनिक्स समय या POSIX समय भी कहा जाता है। इसमें कुछ भी इस बात पर निर्भर नहीं करता कि आप कहाँ हैं: एपॉक समय UTC में परिभाषित है, इसलिए एक ही पल का मान पूरी दुनिया में एक ही रहता है, और अलग-अलग क्षेत्रों में बैठी दो मशीनें स्थानीय घड़ी पर असहमत होकर भी टाइमस्टैम्प पर सहमत रहती हैं।

टाइमस्टैम्प को तारीख़ में कैसे बदलें?

मान डालिए, बताइए कि वह सेकंड गिनता है या मिलीसेकंड, और लौटती हुई तारीख़ तथा समय पढ़ लीजिए। सबसे पहले जाँचने वाली बात अंकों की संख्या है: इस सदी की किसी तारीख़ के लिए सेकंड की गिनती में दस अंक होते हैं और मिलीसेकंड की गिनती में तेरह। तेरह अंकों वाला मान सेकंड की तरह पढ़ा जाए तो हज़ारों साल आगे जा पड़ता है और ठुकरा दिया जाता है; दस अंकों वाला मान मिलीसेकंड की तरह पढ़ा जाए तो जनवरी 1970 में जा गिरता है, और यह वह ग़लती है जो अपनी ख़बर ख़ुद नहीं देती। दूसरी दिशा से वापस बदलकर देख लेना सबसे तेज़ पुष्टि है।

2038 समस्या क्या है?

2038 समस्या तब सामने आती है जब कोई सिस्टम टाइमस्टैम्प 32 बिट के चिह्नित पूर्णांक में रखता है: उस प्रकार में इकतीसवीं घात तक की संख्या रखी जा सकती है, जो 2038-01-19T03:14:07 UTC बनती है, और ठीक एक सेकंड बाद काउंटर उछलकर 1901 की किसी तारीख़ पर पहुँच जाता है। यह भंडारण की सीमा है, टाइमस्टैम्प की नहीं, और 64 बिट के काउंटरों पर यह नहीं आती। यह पेज उस मान को और उससे आगे के मानों को भी बिना झिझक बदल देता है, क्योंकि वह 32 बिट के पूर्णांकों में नहीं बल्कि दोहरी परिशुद्धता में हिसाब करता है।

भंडारण के लिए सेकंड रखूँ या मिलीसेकंड?

दोनों जगह-जगह इस्तेमाल होते हैं और कोई भी ग़लत नहीं है, पर अकेला मान यह नहीं बताता कि वह कौन-सा है, इसलिए इकाई को संख्या के साथ चलना चाहिए या पहले से तय रहना चाहिए। मिलीसेकंड सेकंड के अंश बचाए रखते हैं और JavaScript के Date ऑब्जेक्ट तथा कई लॉगिंग सिस्टम वही लिखते हैं; सेकंड वह है जिसे POSIX परिभाषित करता है और जो ज़्यादातर APIs तथा डेटाबेस लौटाते हैं। दोनों के बीच बदलाव बस हज़ार से गुणा है, और यह पेज दोनों पंक्तियाँ साथ छापता है ताकि जोड़ा एक नज़र में दिख जाए।

क्या ISO 8601 प्रारूप और टाइमस्टैम्प एक ही चीज़ हैं?

नहीं, और दोनों में उलझना आसान है क्योंकि दोनों एक ही पल बताते हैं। ISO 8601 लिखने का ढंग है — 2026-01-15T12:00:00Z — और वह पढ़ने लायक है, क्रम में लगाया जा सकता है, और आख़िर का Z उसके UTC ऑफ़सेट के बारे में कोई शक नहीं छोड़ता। यूनिक्स टाइमस्टैम्प बस एक गिनती है, जिसमें कोई ढाँचा ही नहीं। ISO 8601 स्ट्रिंग वह है जिसे आप किसी दस्तावेज़ या URL में चिपकाते हैं; गिनती वह है जिसे आप रखते या मिलाते हैं। यह पेज दोनों एक ही बदलाव से छापता है, इसलिए एक को दूसरे से जाँचा जा सकता है।

• The Open Group Base Specifications — Seconds Since the Epoch — The Open Group — the normative definition of the epoch and of leap-second handling
• RFC 3339 — Date and Time on the Internet: Timestamps — IETF — the format of the Z-suffixed string this page prints
• MDN — Date — MDN Web Docs — the millisecond count and its range in JavaScript