मुफ़्त यूनिक्स एपोक टाइमस्टैंप कनवर्टर

Unix epoch समय वास्तव में क्या है

Unix epoch समय (जिसे POSIX समय, Unix समय, या केवल "epoch" भी कहा जाता है) समय के क्षणों को एक एकल पूर्णांक के रूप में दर्शाने की एक प्रणाली है: Unix epoch से जो 1 जनवरी 1970 को 00:00:00 UTC पर है, बीते सेकंडों (या JavaScript और कई आधुनिक प्रणालियों में मिलीसेकंडों) की संख्या। ऋणात्मक संख्याएँ epoch से पहले के समय का प्रतिनिधित्व करती हैं; धनात्मक, बाद के। एकल-पूर्णांक प्रतिनिधित्व के आकर्षक गुण हैं: यह समय-क्षेत्र-स्वतंत्र है (पृथ्वी पर कहीं भी एक ही क्षण में संख्या समान होती है), तुलना करना आसान है (बाद के समय बड़ी संख्याएँ होती हैं), और अवधि की गणना तुच्छ है (घटाव)। Unix समय वस्तुतः हर ऑपरेटिंग सिस्टम, हर डेटाबेस इंजन, हर API प्रोटोकॉल, और हर प्रोग्रामिंग भाषा के मानक पुस्तकालय में अंतर्निहित समय प्रतिनिधित्व है, यहाँ तक कि वे प्रणालियाँ भी जिनकी उपयोगकर्ता इंटरफ़ेस कैलेंडर तिथियाँ दिखाती हैं, अंतर्निहित मानों को epoch पूर्णांकों के रूप में संग्रहीत करती हैं।

1 जनवरी 1970 का चयन, और अन्य epoch

1970-01-01 epoch Bell Labs में Unix के शुरुआती दिनों से है। Unix का time_t प्रकार मूल रूप से एक चुनी हुई आधार रेखा से सेकंड गिनने वाला 32-बिट हस्ताक्षरित पूर्णांक था; टीम ने विकास शुरू होने से पहले का सबसे हाल का नववर्ष चुना, जो 1 जनवरी 1970 था। निर्णय व्यावहारिक था, दार्शनिक नहीं, Unix 1969-1971 में विकसित हो रहा था, और एक हाल ही की epoch ने 32-बिट हस्ताक्षरित सीमा के भीतर टाइमस्टैम्प की उपयोगी सीमा को अधिकतम किया। अन्य प्रणालियों ने अपने उपयोग के मामलों के अनुकूल अन्य epochs चुनी हैं। NTP (Network Time Protocol, RFC 5905) अपनी epoch के रूप में 1 जनवरी 1900 का उपयोग करता है, महत्वपूर्ण क्योंकि NTP को लंबी ऐतिहासिक श्रेणियों को कवर करने की आवश्यकता थी। Windows FILETIME 1 जनवरी 1601 को 100-नैनोसेकंड-टिक epoch के रूप में उपयोग करता है (400 साल के ग्रेगोरियन चक्र की शुरुआत जिसमें 1601 शामिल था)। VAX/VMS ने 17 नवंबर 1858 का उपयोग किया (संशोधित जूलियन दिन epoch, खगोल विज्ञान में लोकप्रिय)। Mac classic ने 1 जनवरी 1904 का उपयोग किया। JavaScript Date Unix epoch का उपयोग करता है लेकिन सेकंड के बजाय मिलीसेकंड गिनता है (एक 64-बिट फ्लोट, ±100 मिलियन वर्षों की उपयोगी सीमा देता है)। निष्कर्ष: 2026 में Unix epoch प्रमुख है, लेकिन ऐतिहासिक रिकॉर्ड में कई अन्य विकल्प हैं, प्रत्येक अपने स्वयं के बैकवर्ड-संगतता विरासत के साथ।

Y2K38 समस्या, Unix समय समाप्त हो जाएगा (एक तरह से)

यदि time_t एक 32-बिट हस्ताक्षरित पूर्णांक है (मूल Unix डिज़ाइन), तो अधिकतम प्रतिनिधित्व योग्य टाइमस्टैम्प 2,147,483,647 है, जो मंगलवार, 19 जनवरी 2038, 03:14:07 UTC से मेल खाता है। एक सेकंड बाद, मान ऋणात्मक में अतिप्रवाह कर जाता है, 13 दिसंबर 1901 पर लौटता है। यह Y2K38 समस्या है (जिसे Epochalypse भी कहा जाता है)। आधुनिक 64-बिट प्रणालियों पर, time_t एक 64-बिट हस्ताक्षरित पूर्णांक है और अतिप्रवाह तिथि 4 दिसंबर 292,277,026,596 है, सूर्य की मृत्यु के आराम से बाद। लेकिन 32-बिट एम्बेडेड सिस्टम अभी भी औद्योगिक नियंत्रकों, लंबे मिशन वाले उपग्रहों, बैंकिंग बैक-एंड सिस्टम, तेल-और-गैस SCADA नेटवर्क, ऑटोमोटिव इन्फोटेनमेंट, और कई-दशक की डिज़ाइन जीवनकाल वाले IoT सेंसरों में सक्रिय परिनियोजन में हैं। शमन 2000 के दशक की शुरुआत से चल रहा है, हर प्रमुख OS, डेटाबेस, और भाषा अब 64-बिट हार्डवेयर पर डिफ़ॉल्ट रूप से 64-बिट समय का उपयोग करते हैं (Linux ने मार्च 2020 में कर्नेल 5.6 में संक्रमण पूरा किया; Windows ने हमेशा 64-बिट का उपयोग किया; macOS Catalina ने 2019 में 32-बिट समर्थन छोड़ दिया)। एम्बेडेड सिस्टम लंबी पूँछ हैं। Y2K38 समस्या Y2K की तरह एक-दिन का संकट नहीं होगी; यह 2038 के निकट के वर्षों में लंबी पूँछ की प्रणालियों में छोटी विफलताओं की एक श्रृंखला होगी, ठीक उसी तरह जैसे Y2K मुख्यतः उन अस्पष्ट प्रणालियों में प्रकट हुआ जिन्हें किसी ने पैच नहीं किया था।

ISO 8601, दूसरा मानक समय प्रारूप

जहाँ Unix समय वायर प्रारूप है, ISO 8601 मानव-पठनीय प्रारूप है। मूल रूप से ISO 8601:1988 के रूप में प्रकाशित, 2000, 2004 में संशोधित, और सबसे हाल में ISO 8601-1:2019 और ISO 8601-2:2019 में, यह मानक 2026-05-03T14:30:00Z (जहाँ Z का अर्थ UTC है) या 2026-05-03T14:30:00+01:00 (स्पष्ट ऑफ़सेट के साथ) जैसे प्रतिनिधित्व परिभाषित करता है। "T" तिथि को समय से अलग करता है; पीछे का ऑफ़सेट समय-क्षेत्र की अस्पष्टता को दूर करता है। इंटरनेट प्रोटोकॉल के लिए, RFC 3339 (Klyne और Newman, 2002) ISO 8601 का एक सख़्त उपसमुच्चय परिभाषित करता है जो पार्स करना आसान है, यह वह प्रारूप है जो आप JSON API प्रतिक्रियाओं, लॉग टाइमस्टैम्प, JWT exp/iat क्षेत्रों, और OAuth प्रवाह में देखेंगे। Unix समय से संबंध: ISO 8601 एक क्षण का मानव-पठनीय रूप है; Unix समय उसी क्षण का पूर्णांक रूप है। इस तरह का एक कनवर्टर उनके बीच किसी भी दिशा में जाता है। स्थानीय-समय रूप (2026-05-03T14:30:00 बिना ऑफ़सेट के) अस्पष्ट है और किसी भी ऐसी प्रणाली में टाला जाना चाहिए जो समय क्षेत्रों को पार करती है, यह अक्सर सूक्ष्म बग्स का स्रोत होता है जहाँ एक JSON API टाइमस्टैम्प लौटाने का दावा करता है लेकिन यह नहीं बताता कि वे किस समय क्षेत्र में हैं।

सेकंड बनाम मिलीसेकंड, सामान्य भ्रम

ऑपरेटिंग सिस्टम स्तर पर Unix समय सेकंड गिनता है, लगभग 2001 और 2286 के बीच के किसी भी समय के लिए 10-अंकीय पूर्णांक (2001 से पहले के टाइमस्टैम्प में 9 अंक या उससे कम थे)। JavaScript का Date.now(), JVM का System.currentTimeMillis(), .NET का DateTimeOffset.ToUnixTimeMilliseconds(), और अधिकांश वेब API मिलीसेकंड गिनते हैं, उसी सीमा के लिए 13-अंकीय पूर्णांक। दो रूप ठीक 1,000 के एक कारक से भिन्न होते हैं, और कई प्रणालियों से बात करने वाले किसी भी कोड में सबसे आम टाइमस्टैम्प-संबंधित बग एक मिलीसेकंड मान को सेकंड की अपेक्षा करने वाले फ़ंक्शन में डालना है (जिससे इच्छित से 1,000× आगे की तिथि मिलती है) या इसके विपरीत (epoch के बाद एक सेकंड के अंश की तिथि देता है)। यह कनवर्टर अंकों की संख्या के आधार पर स्वतः-पता लगाता है: 10 अंक या उससे कम = सेकंड, 13 या अधिक = मिलीसेकंड। बीच के मानों के लिए (11–12 अंक, अस्पष्ट), कनवर्टर वह व्याख्या पसंद करता है जो एक उचित तिथि देती है। माइक्रोसेकंड (16 अंक, कुछ उच्च-सटीकता प्रणालियों और कई डेटाबेस TIMESTAMP प्रकारों द्वारा उपयोग किया जाता है) और नैनोसेकंड (19 अंक, Linux clock_gettime, Go के time.UnixNano(), OpenTelemetry जैसे आधुनिक अवलोकन-योग्यता उपकरण द्वारा उपयोग किया जाता है) भी मिलते हैं लेकिन उपयोगकर्ता-सामना डेटा में कम सामान्य हैं।

जहाँ आपको वास्तव में इस रूपांतरण की आवश्यकता है

• API प्रतिक्रियाएँ पढ़ना। एक REST एंडपॉइंट "created_at": 1714665600 लौटाता है, वह कौन सी तिथि है? पेस्ट करें, "2 मई, 2024 16:00:00 UTC" देखें, डिबग सत्र के साथ आगे बढ़ें। Stripe, GitHub, AWS, और अधिकांश एंटरप्राइज़ API समय-क्षेत्र अस्पष्टता से बचने के लिए विशेष रूप से तिथि क्षेत्रों के लिए Unix-समय पूर्णांकों का उपयोग करते हैं।
• लॉग टाइमस्टैम्प को डिकोड करना। सर्वर लॉग अक्सर कॉम्पैक्टनेस और पार्सिंग गति के लिए समय को Unix पूर्णांकों के रूप में रिकॉर्ड करते हैं। "1714665600.234 ERROR connection refused" पढ़ने के लिए अग्रणी संख्या को कैलेंडर समय में परिवर्तित करना आवश्यक है ताकि अन्य घटनाओं के साथ सहसंबंध स्थापित किया जा सके।
• JWT डिबगिंग। JSON वेब टोकन में exp (समाप्ति) और iat (जारी-समय) दावे RFC 7519 के अनुसार Unix-समय पूर्णांक हैं। यह जाँचने के लिए कि क्या टोकन समाप्त हो गया है या यह देखने के लिए कि वह कब जारी किया गया था, यहाँ मान पेस्ट करें।
• समय-अंतर गणना। उनके बीच की अवधि सेकंड (या मिलीसेकंड) में प्राप्त करने के लिए दो Unix टाइमस्टैम्प घटाएँ। समय-क्षेत्र गणित नहीं, DST समायोजन नहीं, कैलेंडर-अंकगणित किनारे के मामले नहीं।
• epoch कॉलम के साथ डेटाबेस क्वेरी। कई पुराने डेटाबेस टाइमस्टैम्प को Unix पूर्णांकों के रूप में संग्रहीत करते हैं। "X और Y के बीच की सभी घटनाओं" को क्वेरी करने के लिए मानव-पठनीय कटऑफ़ तिथियों को WHERE खंड के लिए Unix पूर्णांकों में बदलना आवश्यक है।
• शेड्यूलिंग और cron कार्य। जो प्रणालियाँ पूर्ण समय द्वारा कार्यों को शेड्यूल करती हैं (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps) अक्सर अपने कॉन्फ़िगरेशन में Unix-समय लक्ष्य चाहती हैं। मानव-अनुकूल लक्ष्य समय को epoch में बदलें।
• "दिलचस्प" टाइमस्टैम्प को डिकोड करना। प्रसिद्ध epoch मान: 0 = 1 जनवरी 1970 00:00:00 UTC (epoch स्वयं); 1234567890 = 13 फरवरी 2009 23:31:30 UTC (संक्षेप में "Unix billion" क्षण के रूप में मनाया गया); 1500000000 = 14 जुलाई 2017 02:40:00 UTC; 2000000000 = 18 मई 2033 03:33:20 UTC; 2147483647 = 19 जनवरी 2038 03:14:07 UTC (Y2K38 अतिप्रवाह बिंदु)।

लीप सेकंड और "वास्तविक" समय पर एक नोट

एक सूक्ष्म जटिलता: POSIX द्वारा परिभाषित Unix समय लीप सेकंड शामिल नहीं करता। समन्वित सार्वभौमिक समय (UTC) कभी-कभी पृथ्वी के वास्तविक घूर्णन के साथ नागरिक समय को संरेखित रखने के लिए एक लीप सेकंड जोड़ता है, 1972 में सिस्टम शुरू होने के बाद से 27 लीप सेकंड जोड़े गए हैं। Unix समय यह दिखावा करता है कि वे लीप सेकंड हुए ही नहीं: जब किसी दिन के अंत में एक लीप सेकंड डाला जाता है, तो घड़ी या तो अंतिम सेकंड दोहराती है (Linux का पारंपरिक व्यवहार) या इसे लंबी अवधि में फैला देती है (Google का "लीप स्मीयर" दृष्टिकोण, AWS और कई CDN द्वारा अपनाया गया)। अधिकांश एप्लिकेशन उपयोग के लिए, यह कोई फ़र्क नहीं पड़ता, सब-सेकंड समय सटीकता एप्लिकेशन स्तर पर शायद ही कभी सार्थक होती है। उच्च-सटीकता वैज्ञानिक कार्य, वित्तीय व्यापार-प्रणाली टाइमस्टैम्प, या कानूनी-साक्ष्य संबंधी टाइमस्टैम्प के लिए, लीप-सेकंड व्यवहार किनारे के मामलों का एक ज्ञात स्रोत है। IERS (International Earth Rotation and Reference Systems Service) छह महीने की सूचना के साथ लीप सेकंड की घोषणा करता है; सबसे हाल का 31 दिसंबर 2016 के अंत में डाला गया था, और अंतर्राष्ट्रीय समुदाय लीप सेकंड को पूरी तरह से सेवानिवृत्त करने पर विचार कर रहा है (2035 तक ऐसा करने का प्रस्ताव 2022 के सामान्य सम्मेलन में भार और माप पर अपनाया गया था)।

गोपनीयता: केवल ब्राउज़र-में रूपांतरण

जो टाइमस्टैम्प आप पेस्ट करते हैं वे आमतौर पर स्वयं संवेदनशील नहीं होते (एक Unix पूर्णांक केवल समय में एक क्षण को प्रकट करता है), लेकिन संदर्भ, टाइमस्टैम्प के साथ एक वास्तविक उपयोगकर्ता पहचानकर्ता वाली एक लॉग पंक्ति, एक वास्तविक उपयोगकर्ता के बारे में दावे वाला एक JWT, आंतरिक एंटिटी ID वाली एक API प्रतिक्रिया, अक्सर होता है। यह कनवर्टर JavaScript की अंतर्निहित Date API के माध्यम से पूरी तरह से आपके ब्राउज़र में चलता है। कोई अपलोड नहीं, कोई लॉगिंग नहीं, टाइमस्टैम्प टाइप करते समय DevTools के नेटवर्क टैब में सत्यापित करें (कोई अनुरोध फायर नहीं होता), या लोड होने के बाद पृष्ठ को ऑफ़लाइन (हवाई जहाज मोड) में लें। लाइव-अपडेटिंग "now" डिस्प्ले आपकी स्थानीय घड़ी का उपयोग करता है, नेटवर्क समय स्रोत का नहीं।

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

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

एक Unix टाइमस्टैम्प (जिसे Epoch समय या POSIX समय भी कहा जाता है) 1 जनवरी 1970 को 00:00:00 UTC पर बीते सेकंडों की संख्या है, Unix के POSIX अमूर्तन (जो लीप सेकंड नहीं गिनता) के अनुसार बजाय वास्तविक बीते परमाणु-घड़ी सेकंडों के। कई आधुनिक प्रणालियाँ सब-सेकंड सटीकता के लिए सेकंड के बजाय मिलीसेकंड का उपयोग करती हैं (JavaScript का Date.now(), Java का System.currentTimeMillis(), .NET का DateTimeOffset.ToUnixTimeMilliseconds())। Unix समय वस्तुतः हर ऑपरेटिंग सिस्टम, डेटाबेस, और वेब API में मानक समय प्रतिनिधित्व है।

सेकंड और मिलीसेकंड में क्या अंतर है?

1,000 का एक कारक। 2026 में सेकंड-सटीकता वाले Unix टाइमस्टैम्प 10 अंकों के होते हैं (उदा., 1714665600); मिलीसेकंड-सटीकता वाले 13 अंकों के होते हैं (उदा., 1714665600234)। यह कनवर्टर अंक संख्या के आधार पर स्वतः-पता लगाता है। दो रूपों को मिलाने वाले कोड में सबसे आम बग सेकंड की अपेक्षा करने वाले फ़ंक्शन में मिलीसेकंड डालना है (जिससे इच्छित से 1,000× आगे की तिथि मिलती है) या इसके विपरीत।

मेरा कनवर्ट किया गया समय कई घंटे क्यों बंद है?

Unix समय समय-क्षेत्र-स्वतंत्र है, लेकिन मानव-पठनीय रूप उस समय क्षेत्र पर निर्भर करता है जिसमें आप इसे प्रदर्शित करते हैं। कनवर्टर एक साथ तीन प्रारूप दिखाता है: स्थानीय समय (आपके ब्राउज़र का समय क्षेत्र), UTC (ग्रीनविच), और ISO 8601 (स्पष्ट ऑफ़सेट के साथ)। यदि परिणाम आपकी अपेक्षा से मेल नहीं खाता, तो समय क्षेत्र की जाँच करें, आपका "अपेक्षित" मान शायद आप जिस प्रारूप को पढ़ रहे थे उससे भिन्न समय क्षेत्र में था।

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

यदि Unix समय एक 32-बिट हस्ताक्षरित पूर्णांक में संग्रहीत है (मूल Unix डिज़ाइन), तो यह 19 जनवरी 2038 को 03:14:07 UTC पर अतिप्रवाह करता है। आधुनिक 64-बिट प्रणालियाँ अप्रभावित हैं, अतिप्रवाह तिथि लगभग वर्ष 292 अरब तक चली जाती है। Y2K38 जोखिम अभी भी परिनियोजन में 32-बिट एम्बेडेड सिस्टमों में केंद्रित है (औद्योगिक नियंत्रक, उपग्रह, ऑटोमोटिव इन्फोटेनमेंट, बैंकिंग बैक-एंड, कई-दशक की जीवन वाले IoT सेंसर)। Y2K के विपरीत, Y2K38 समस्या एक-दिन का संकट नहीं होगी बल्कि 2038 के निकट के वर्षों में लंबी पूँछ की प्रणालियों में छोटी विफलताओं की एक श्रृंखला होगी।

क्या यह ऑफ़लाइन काम करता है?

हाँ, एक बार पेज लोड होने के बाद, सभी रूपांतरण JavaScript की अंतर्निहित Date API के माध्यम से आपके ब्राउज़र में चलते हैं। उपयोग के दौरान कोई नेटवर्क कॉल नहीं। "Now" बटन आपके डिवाइस की स्थानीय घड़ी का उपयोग करता है; शीर्ष पर लाइव-अपडेटिंग टाइमस्टैम्प किसी भी समय सर्वर से संपर्क किए बिना आपकी सिस्टम घड़ी से अपडेट होता है।

संबंधित टूल