यूनिक्स टाइमस्टैम्प कन्वर्टर
किसी यूनिक्स टाइमस्टैम्प (epoch) को मानव-पठनीय तारीख़ में और वापस बदलें। सेकंड या मिलीसेकंड, UTC, ISO 8601, लोकल और सापेक्ष आउटपुट के साथ। पूरी तरह आपके ब्राउज़र में चलता है। अंतिम समीक्षा 2026-06-19.
मौजूदा यूनिक्स समय: …
टाइमस्टैम्प → तारीख़
- UTC
- —
- ISO 8601
- —
- लोकल
- —
- सापेक्ष
- —
तारीख़ → टाइमस्टैम्प
यूनिक्स टाइमस्टैम्प क्या है
एक यूनिक्स टाइमस्टैम्प (epoch / POSIX समय) 1 जनवरी 1970 00:00:00 UTC से
बीते सेकंडों को गिनता है, लीप सेकंड को अनदेखा करते हुए। चूँकि यह UTC में एक अकेली संख्या है,
यह समय-क्षेत्र से स्वतंत्र एक सटीक क्षण संग्रहीत करता है — यही वजह है कि डेटाबेस, लॉग और API इसका
उपयोग करते हैं। उदाहरण के लिए, 1700000000 है Tue, 14 Nov 2023 22:13:20 GMT (ISO 8601:
2023-11-14T22:13:20.000Z)।
सेकंड बनाम मिलीसेकंड
पारंपरिक यूनिक्स समय सेकंड में होता है (मौजूदा मान 10 अंक का होता है)। JavaScript और कई प्लेटफ़ॉर्म मिलीसेकंड (13 अंक) का उपयोग करते हैं। यदि आप इकाई “स्वतः पहचानें” पर रखते हुए 13-अंक का मान पेस्ट करते हैं, तो यह टूल उसे मिलीसेकंड मानता है। सेकंडों में सामान्य अंतराल:
| अंतराल | सेकंड |
|---|---|
| मिनट | 60 |
| घंटा | 3,600 |
| दिन | 86,400 |
| सप्ताह | 604,800 |
| वर्ष (365 दिन) | 31,536,000 |
वर्ष 2038 समस्या
जो सॉफ़्टवेयर टाइमस्टैम्प को साइन-युक्त 32-बिट पूर्णांक में संग्रहीत करता है वह केवल 2,147,483,647 सेकंड तक ही गिन सकता है — जो 19 जनवरी 2038 को 03:14:07 UTC पर पहुँच जाता है। उसके आगे मान ओवरफ़्लो होकर ऋणात्मक संख्या बन जाता है। उपाय है समय को 64-बिट पूर्णांक में संग्रहीत करना, जो सभी आधुनिक सिस्टम करते हैं।
1970 epoch कहाँ से आया
परिचित 1970 प्रारंभ-बिंदु पहला नहीं था। यूनिक्स प्रोग्रामर मैनुअल का सबसे पुराना संस्करण, जो नवंबर 1971 में Bell Labs में लिखा गया, सिस्टम समय को 1 जनवरी 1971 को 00:00:00 से बीते सेकंड के साठवें हिस्सों की संख्या के रूप में परिभाषित करता था। 1/60-सेकंड टिकों में गिनना उस 60 Hz लाइन-आवृत्ति से मेल खाता था जिससे शुरुआती PDP-11 हार्डवेयर अपनी घड़ी चलाता था, पर सेकंड में 60 बार आगे बढ़ने वाला 32-बिट काउंटर अपनी सीमा केवल लगभग 2.26 वर्षों में समाप्त कर देता है — एक बाद के मैनुअल ने साफ़ लिखा कि यह "हर 2.26 वर्ष में एक संकट की गारंटी देता है।"
उपाय, जो 1972–1973 के मैनुअलों में तय हुआ, दोहरा था: टिकों के बजाय पूरे सेकंड गिनो, और शून्य-बिंदु को 1 जनवरी 1970 UTC की गोल तारीख़ पर ले जाओ। साठवें हिस्सों से सेकंडों पर जाना एक ही झटके में उपयोगी सीमा को साठ गुना कर देता है, और इंजीनियरों — Ken Thompson, Dennis Ritchie और सहयोगियों — ने 1970 इसलिए चुना क्योंकि यह काम करने के लिए एक सुविधाजनक, सुथरी संख्या थी। वह मनमाना, व्यावहारिक चुनाव तब से कंप्यूटिंग के सबसे चुपचाप भार-वहन करने वाले स्थिरांकों में से एक बन गया है: हर आधुनिक ऑपरेटिंग सिस्टम, डेटाबेस और प्रोग्रामिंग भाषा आज भी उसी ठीक-ठीक क्षण से गिनती है।
लीप सेकंड, और हर यूनिक्स दिन ठीक 86,400 सेकंड का क्यों होता है
POSIX मानक यूनिक्स समय को इस तरह परिभाषित करता है कि हर दिन में ठीक 86,400 सेकंड होते हैं (60 × 60 × 24)। यह स्पष्ट लगता है जब तक आपको याद न आए कि नागरिक समय UTC है, और UTC कभी-कभी पृथ्वी के थोड़े अनियमित घूर्णन के साथ घड़ियों को संरेखित रखने के लिए एक लीप सेकंड जोड़ता है। धनात्मक लीप सेकंड वाले दिन UTC वास्तव में 86,401 सेकंड चलता है — पर यूनिक्स समय को इसे मानने से अनुबंधतः मना है, इसलिए यह अतिरिक्त सेकंड को गिनता ही नहीं।
परिणाम एक छोटी पर वास्तविक अस्पष्टता है। उदाहरण के लिए, सीमा-मान 1483228800 या तो लीप
सेकंड 2016-12-31 23:59:60 UTC का अर्थ रख सकता है या एक टिक बाद के सामान्य सेकंड
2017-01-01 00:00:00 UTC का — दो अलग वास्तविक-जगत क्षण एक ही टाइमस्टैम्प साझा करते
हुए, क्योंकि वही यूनिक्स मान लगातार दो सेकंडों के लिए इस्तेमाल होता है ताकि अगली आधी रात फिर भी 86,400
के साफ़ गुणज पर पड़े। व्यावहारिक नतीजा: एक संग्रहीत यूनिक्स टाइमस्टैम्प किसी लीप सेकंड को स्पष्ट रूप से
प्रस्तुत नहीं कर सकता, और किसी लीप सेकंड के आर-पार पड़ने वाले दो टाइमस्टैम्पों के बीच का अंतर बीच के
लीप सेकंडों की संख्या जितना ग़लत होता है। अधिकांश सॉफ़्टवेयर के लिए यह अदृश्य है; उच्च-परिशुद्धता वाले
सिस्टम TAI का उपयोग करते हैं या लीप सेकंड को पूरे दिन में धीरे-धीरे "स्मियर" कर देते हैं।
ऋणात्मक टाइमस्टैम्प: epoch से पहले के समय को संबोधित करना
चूँकि time_t एक साइन-युक्त पूर्णांक है, टाइमस्टैम्प 1970 के बाद की तारीख़ों तक
सीमित नहीं हैं — वे अतीत की ओर इशारा करने के लिए ऋणात्मक हो सकते हैं, epoch से पहले
हर सेकंड के लिए एक-एक घटते हुए। 1 जनवरी 1969 UTC की आधी रात -31536000 है (ठीक एक
ग़ैर-लीप वर्ष पहले), और साइन-युक्त 32-बिट फ़ील्ड जो सबसे ऋणात्मक मान रख सकता है,
-2147483648, 13 दिसंबर 1901 को 20:45:52 UTC पर पड़ता है — 2038 सीमा का
दर्पण-प्रतिबिंब। ऐतिहासिक तारीख़ें संग्रहीत करते समय ऋणात्मक epoch सामान्य हैं, पर ये बार-बार बग का
स्रोत बनते हैं: कोई लाइब्रेरी या डेटाबेस कॉलम जो मान लेता है कि टाइमस्टैम्प अनसाइन्ड हैं, 1970 से पहले
की किसी भी चीज़ को ग़लत तरीक़े से संभालेगा, और कुछ पुराने सिस्टम ऋणात्मक मानों को सीधे अस्वीकार कर देते
हैं।
उप-सेकंड परिशुद्धता: मिलीसेकंड, माइक्रोसेकंड, नैनोसेकंड
सादा यूनिक्स समय एक-सेकंड की रिज़ॉल्यूशन रखता है, पर अधिकांश प्लेटफ़ॉर्म इसे बढ़ाते हैं, और अंकों की
गिनती सबसे तेज़ पहचान है: एक वर्तमान मान सेकंड में 10 अंक, मिलीसेकंड में 13, माइक्रोसेकंड में
16 और नैनोसेकंड में 19 अंक का होता है। JavaScript मूलतः मिलीसेकंड में काम करता है —
Date.now() एक 13-अंक मान लौटाता है — इसलिए पारंपरिक सेकंडों में बदलने के लिए 1,000 से भाग
देना होता है। Python का time.time() माइक्रोसेकंड परिशुद्धता के साथ सेकंडों की एक
फ़्लोटिंग-पॉइंट संख्या लौटाता है, जबकि time.time_ns() नैनोसेकंडों की एक पूर्णांक गिनती
लौटाता है। Go का time.Now().UnixNano() और कई डेटाबेस भी नैनोसेकंड तक पहुँचते हैं। इन
इकाइयों को मिलाना सबसे आम epoch बग है — नीचे दिए नुकसान देखें।
किसी भी वातावरण में मौजूदा epoch पढ़ना
लगभग हर भाषा और शेल मौजूदा यूनिक्स समय को सीधे उजागर करता है। नीचे की तालिका कई सामान्य वातावरणों में मुहावरेदार कॉल सूचीबद्ध करती है (जब तक अन्यथा न कहा जाए, हर एक पूरे सेकंड लौटाता है):
| वातावरण | epoch कैसे पढ़ें |
|---|---|
| शेल (Linux / macOS) | date +%s |
| JavaScript | Math.floor(Date.now() / 1000) — Date.now() मिलीसेकंड में है |
| Python | int(time.time()) |
| PHP | time() |
| Go | time.Now().Unix() |
| Java | Instant.now().getEpochSecond() — मिलीसेकंड के लिए currentTimeMillis() |
| PostgreSQL | SELECT EXTRACT(EPOCH FROM now()) |
| MySQL | SELECT UNIX_TIMESTAMP() |
यूनिक्स ही एकमात्र शून्य-बिंदु नहीं है
अलग-अलग सिस्टम अलग-अलग epoch के इर्द-गिर्द डिज़ाइन किए गए थे, यही वजह है कि "किसी epoch से बीते सेकंड" तब तक अर्थहीन है जब तक आप न जानें कि कौन-सा epoch, और यही वजह है कि रूपांतरण के बिना टाइमस्टैम्प प्लेटफ़ॉर्मों के बीच पोर्टेबल नहीं होते। सबसे महत्वपूर्ण संदर्भ-बिंदु:
| सिस्टम | epoch (शून्य-बिंदु) | इकाई | टिप्पणी |
|---|---|---|---|
| Unix / POSIX | 1970-01-01 UTC | सेकंड | वेब और अधिकांश ऑपरेटिंग सिस्टम। |
| NTP | 1900-01-01 UTC | सेकंड | 32-बिट सेकंड-काउंटर 7 फ़रवरी 2036 को रोल-ओवर करता है। |
| GPS | 1980-01-06 UTC | सेकंड / सप्ताह | लीप सेकंड को अनदेखा करता है, इसलिए अब यह UTC से 18 सेकंड आगे चलता है। |
| Windows FILETIME | 1601-01-01 UTC | 100-नैनोसेकंड टिक | 1601 एक 400-वर्षीय ग्रेगोरियन चक्र शुरू करता है। |
| Excel सीरियल तारीख़ | 1899-12-30 | दिन | 1900 को लीप वर्ष मानता है (Lotus 1-2-3 संगतता के लिए रखा गया बग)। |
Excel की विचित्रता क्लासिक गड़बड़ है: Lotus 1-2-3 के साथ बग-संगत रहने के लिए, Excel मानता है कि अस्तित्वहीन तारीख़ 29 फ़रवरी 1900 वास्तविक थी, इसलिए 1900 की शुरुआत की किसी भी तारीख़ के लिए उसका दिन-काउंटर एक से ग़लत होता है, और भरपाई के लिए उसका प्रभावी epoch 30 दिसंबर 1899 पर टिका है। Windows 1601 इसलिए उपयोग करता है क्योंकि वह वर्ष ग्रेगोरियन कैलेंडर के 400-वर्षीय चक्र की शुरुआत करता है, जिससे लीप-वर्ष की गणना साफ़ रहती है।
माइलस्टोन टाइमस्टैम्प और 292-अरब-वर्ष क्षितिज
चूँकि यूनिक्स समय बस एक काउंटर है, कुछ गोल या रोचक मान छोटे-मोटे गीक त्योहार बन गए हैं:
| टाइमस्टैम्प | क्षण (UTC) | यह उल्लेखनीय क्यों है |
|---|---|---|
1000000000 | 2001-09-09 01:46:40 | पहला "यूनिक्स बिलेनियम" — एक अरब सेकंड। |
1234567890 | 2009-02-13 23:31:30 | अंक 1-2-3-4-5-6-7-8-9-0 क्रम में; Google ने एक डूडल चलाया। |
1700000000 | 2023-11-14 22:13:20 | इस पेज के ऊपर दिए वर्क्ड उदाहरण में इस्तेमाल किया गया मान। |
2000000000 | 2033-05-18 03:33:20 | दूसरा बिलेनियम। |
2147483647 | 2038-01-19 03:14:07 | साइन-युक्त 32-बिट सीमा — वर्ष 2038 रोल-ओवर। |
2038 के आगे दीर्घकालिक उत्तर पहले ही तैनात है: गिनती को साइन-युक्त 64-बिट पूर्णांक में
संग्रहीत करना ओवरफ़्लो को 1970 के किसी भी ओर लगभग 292 अरब वर्ष आगे धकेल देता है —
सूर्य के अनुमानित जीवनकाल से कहीं आगे। आधुनिक Linux, C लाइब्रेरी और अधिकांश भाषाएँ वर्षों पहले 64-बिट
time_t पर आ गईं; बची हुई 2038 जोखिम पुराने 32-बिट बाइनरी, एम्बेडेड फ़र्मवेयर और उन पुराने
ऑन-डिस्क या ऑन-वायर फ़ॉर्मैटों में रहती है जो अब भी टाइमस्टैम्प को 32 बिट में पैक करते हैं।
epoch के साथ काम करते समय आम नुकसान
- सेकंड बनाम मिलीसेकंड। 10-अंक मान सेकंड है; 13 अंक मिलीसेकंड। मिलीसेकंड की अपेक्षा करने वाले API को सेकंड देना तारीख़ को वापस 1970 में गिरा देता है, और उल्टा करने से वह हज़ारों वर्ष भविष्य में उछल जाती है।
- छूटा हुआ (या अतिरिक्त) ×1000। JavaScript का
new Date(n)मिलीसेकंड की अपेक्षा करता है, इसलिए सेकंड मान देने परn * 1000चाहिए — इसे भूलना सबसे आम epoch बग है। - epoch को लोकल समय मानना। यूनिक्स टाइमस्टैम्प हमेशा UTC होता है। समय-क्षेत्र निर्दिष्ट किए बिना इसे प्रस्तुत करना दिखाए गए समय को आपकी मशीन के ऑफ़सेट जितना चुपचाप खिसका देता है।
- ऑफ़-बाय-वन राउंडिंग। मिलीसेकंड को सेकंड में बदलते समय आमतौर पर फ़्लोर करना चाहिए, राउंड नहीं, वरना कोई घटना वास्तविक समय के एक सेकंड बाद घटी हुई दिख सकती है।
- अनसाइन्ड मान लेना। 1970 से पहले की तारीख़ें ऋणात्मक होती हैं; जो कोड या कॉलम ग़ैर-ऋणात्मक टाइमस्टैम्प मान लेते हैं वे ऐतिहासिक डेटा को बिगाड़ देंगे।
वॉल-क्लॉक समय बनाम मोनोटोनिक समय
एक जाल जो अनुभवी डेवलपरों को भी फँसाता है: यूनिक्स टाइमस्टैम्प वॉल-क्लॉक समय है, और
वॉल-क्लॉक समय छलांग लगा सकता है। NTP सुधार इसे आगे-पीछे खिसकाते हैं, एक व्यवस्थापक इसे रीसेट कर सकता
है, समय-क्षेत्र-डेटाबेस अपडेट लोकल प्रस्तुति बदल देते हैं, और लीप-सेकंड स्मियरिंग जानबूझकर एक दिन के
लिए इसे धीमा या तेज़ करती है। परिणामस्वरूप, किसी ऑपरेशन में कितना समय लगा यह मापने के लिए दो यूनिक्स
टाइमस्टैम्प घटाना ऋणात्मक या बेतरतीब ग़लत अवधि लौटा सकता है यदि बीच में घड़ी समायोजित हो गई हो।
बीते समय को मापने के लिए आपको इसके बजाय एक मोनोटोनिक घड़ी पढ़नी चाहिए — जो
केवल आगे बढ़ती है और वॉल-क्लॉक समायोजनों से अछूती रहती है — जैसे ब्राउज़र में
performance.now(), Python में time.monotonic(), या Linux पर
CLOCK_MONOTONIC। कुछ कब हुआ यह रिकॉर्ड करने के लिए यूनिक्स epoch का उपयोग करें;
कुछ में कितना समय लगा यह मापने के लिए मोनोटोनिक घड़ी का।
फ़ॉर्मैट की गई तारीख़ के बजाय epoch क्यों संग्रहीत करें
जब आप संग्रहण फ़ॉर्मैट नियंत्रित करते हैं, एक कच्चा यूनिक्स पूर्णांक लगभग हमेशा मानव-पठनीय स्ट्रिंग से
बेहतर विकल्प होता है। यह संक्षिप्त है, एक सादी संख्या की तरह सही ढंग से क्रमबद्ध होता है, तुलना और
गणित करने में तुच्छ है, और — महत्वपूर्ण रूप से — कोई समय-क्षेत्र अस्पष्टता नहीं रखता, क्योंकि यह हमेशा
UTC है। तुलना में "01/02/03" जैसी स्ट्रिंग निराशाजनक है: यह लोकेल के अनुसार तीन अलग तारीख़ें हो सकती है,
और इसे घटाया नहीं जा सकता। जब आपको वाक़ई टेक्स्ट चाहिए तो मानक विनिमय फ़ॉर्मैट ISO 8601 /
RFC 3339 है (उदाहरण के लिए 2009-02-13T23:31:30Z), जिसका अंतिम "Z" इसे UTC पर
टिकाता है और जिसका शाब्दिक क्रम कालानुक्रमिक क्रम से मेल खाता है। अंगूठे का नियम: epoch (या एक
स्पष्ट-UTC ISO 8601 स्ट्रिंग) संग्रहीत और प्रसारित करें, और इसे लोकल, मानव-अनुकूल टेक्स्ट में केवल
अंतिम क्षण पर, यूज़र इंटरफ़ेस में फ़ॉर्मैट करें।
अक्सर पूछे जाने वाले सवाल
- यूनिक्स टाइमस्टैम्प क्या है?
- यूनिक्स टाइमस्टैम्प (जिसे epoch या POSIX समय भी कहते हैं) 1 जनवरी 1970 को 00:00:00 UTC ("यूनिक्स epoch") से बीते सेकंडों की संख्या है, लीप सेकंड गिने बिना। यह किसी क्षण को समय-क्षेत्र-निरपेक्ष तरीक़े से संग्रहीत करने का एक ढंग है।
- टाइमस्टैम्प सेकंड में है या मिलीसेकंड में?
- यूनिक्स टाइमस्टैम्प पारंपरिक रूप से सेकंड में होते हैं (मौजूदा तारीख़ों के लिए 10 अंक)। JavaScript, Java और कई API मिलीसेकंड (13 अंक) का उपयोग करते हैं। यह टूल आपको इकाई चुनने देता है, और 13-अंक वाले इनपुट को स्वतः मिलीसेकंड मान लेता है।
- वर्ष 2038 समस्या क्या है?
- जो सिस्टम टाइमस्टैम्प को साइन-युक्त 32-बिट पूर्णांक में संग्रहीत करते हैं, वे 19 जनवरी 2038 को 03:14:07 UTC पर ओवरफ़्लो कर जाते हैं, जब मान 2,147,483,647 से अधिक हो जाता है। आधुनिक 64-बिट सिस्टम अप्रभावित रहते हैं; उपाय है समय को 64-बिट पूर्णांक में संग्रहीत करना।
- क्या रूपांतरण आपके सर्वर पर होता है?
- नहीं। यह पूरी तरह आपके ब्राउज़र में नेटिव Date API से चलता है, इसलिए आपके मान कभी अपलोड नहीं होते। एक बार लोड होने के बाद यह ऑफ़लाइन भी काम करता है।