मुफ़्त Unix Timestamp कनवर्टर

Unix टाइमस्टैम्प और मानव-पठनीय तारीखों के बीच परिवर्तित करें।

कोई डेटा आपके डिवाइस से बाहर नहीं जाता

वर्तमान Unix टाइमस्टैम्प

टाइमस्टैम्प → तारीख

तारीख → टाइमस्टैम्प

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

Unix टाइमस्टैम्प (जिसे epoch time या POSIX time भी कहा जाता है) 1 जनवरी 1970, 00:00:00 UTC के बाद से बीते सेकंडों की संख्या है। यह समय के एक बिंदु को दर्शाने का एक सरल, टाइमज़ोन-स्वतंत्र तरीका है और इसका व्यापक रूप से प्रोग्रामिंग, डेटाबेस, APIs और सर्वर लॉग में उपयोग किया जाता है।

उदाहरण के लिए, टाइमस्टैम्प 1700000000 14 नवंबर 2023 को 22:13:20 UTC को दर्शाता है। JavaScript मिलीसेकंड टाइमस्टैम्प का उपयोग करता है (1000 से गुणा करें), जबकि अधिकांश अन्य भाषाएँ और APIs सेकंड का उपयोग करती हैं।

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

मैं कौन से तारीख प्रारूप दर्ज कर सकता हूँ?

आप अधिकांश मानक प्रारूपों में तारीखें दर्ज कर सकते हैं: ISO 8601 (2025-12-31T23:59:59Z), सामान्य तारीख स्ट्रिंग (Dec 31, 2025 11:59 PM), या 2025-12-31 23:59:59 जैसे सरल प्रारूप। कनवर्टर आपके ब्राउज़र के अंतर्निहित तारीख पार्सर का उपयोग करता है।

क्या यह स्वचालित रूप से सेकंड बनाम मिलीसेकंड का पता लगाता है?

हाँ। यदि टाइमस्टैम्प 1 ट्रिलियन से बड़ा है, तो कनवर्टर इसे मिलीसेकंड के रूप में मानता है। अन्यथा, इसे सेकंड के रूप में मानता है। दोनों प्रारूप परिणाम तालिका में दिखाए जाते हैं।

वर्ष 2038 की समस्या क्या है?

जो सिस्टम Unix टाइमस्टैम्प को 32-बिट साइन इंटीजर के रूप में संग्रहीत करते हैं, वे 19 जनवरी 2038 को 03:14:07 UTC पर ओवरफ़्लो हो जाएँगे। आधुनिक सिस्टम 64-बिट इंटीजर का उपयोग करते हैं, जो भविष्य में अरबों वर्षों तक तारीखों को दर्शा सकते हैं। यह उपकरण JavaScript के Number प्रकार का उपयोग करता है, जो 2038 से बहुत आगे के टाइमस्टैम्प को संभाल सकता है।

1 जनवरी 1970 ही क्यों?

Unix टाइमस्टैम्प Unix epoch-गुरुवार, 1 जनवरी 1970, 00:00:00 UTC-से बीते सेकंडों की पूर्णांक गणना है। यह एक एकल अदिश है जो समय के एक क्षण को असंदिग्ध रूप से नाम देता है, कैलेंडर- और समय-क्षेत्र-मुक्त: टोक्यो में हों या टोरंटो में, वही संख्या वही क्षण नामित करती है।

1970 का चुनाव कुछ हद तक मनमाना था, पर यादृच्छिक नहीं। UNIX Programmer's Manual के पहले संस्करण (नवंबर 1971) ने सिस्टम समय को 1971-01-01 से 60 Hz घड़ी टिकों की संख्या के रूप में परिभाषित किया। 60 Hz पर गिनती करते 32-बिट बिना चिह्न पूर्णांक के साथ, सिस्टम ओवरफ़्लो से पहले केवल लगभग 2.26 वर्षों तक टिकता-यह समस्या जल्दी ही स्पष्ट हो गई। 1972 में दूसरा संस्करण तैयार करते समय, Ken Thompson और Dennis Ritchie की टीम ने 1970-01-01 से सेकंडों की गिनती पर स्विच किया: सेकंड गिनते 32-बिट सहचिह्न पूर्णांक लगभग 68 वर्षों तक टिकते, कोड लिखने वाले इंजीनियरों के कामकाजी जीवन से बहुत आगे, और परियोजना शुरू होने से ठीक पहले का सबसे ताज़ा नववर्ष अंकगणित को आसान बनाता। कोई समिति-वोट नहीं हुआ, कोई IANA-शैली का मानकीकरण नहीं। चुनाव टिक गया क्योंकि Unix उसी के साथ निकला, और एक बार सौ मिलियन मशीनें उसी क्षण से गिनना शुरू कर देती हैं, तो कोई प्रतिस्थापन व्यावहारिक नहीं रहता।

POSIX (1988) ने 1970 की epoch को IEEE Std 1003.1 की «Seconds Since the Epoch» के रूप में संहिताबद्ध किया। आज वही epoch C/C++ time_t, Python time.time(), Ruby Time.now.to_i, JavaScript और Java (मिलीसेकंडों में, नीचे देखें), Linux/macOS फ़ाइल सिस्टम टाइमस्टैम्प, Bitcoin और Ethereum ब्लॉक हेडर, और JWT iat/exp/nbf क्लेम का आधार है। कुछ सिस्टम विस्थापित epochs उपयोग करते हैं (Windows FILETIME 1601-01-01 से 100-नैनोसेकंड टिक गिनता है, .NET DateTime 0001-01-01 से टिक गिनता है), पर OS या भाषा सीमा पार करने वाली किसी भी चीज़ के लिए Unix समय lingua franca है।

सेकंड बनाम मिलीसेकंड-सबसे आम बग

POSIX टाइमस्टैम्प को epoch से सेकंड के रूप में परिभाषित करता है। हर C लाइब्रेरी, हर Python दुभाषिया, हर Ruby/Go/Rust/Elixir रनटाइम सेकंड लौटाता है। JavaScript प्रसिद्ध अपवाद है-Date.now() और new Date().getTime() मिलीसेकंड लौटाते हैं। Java का System.currentTimeMillis() उसी परंपरा का पालन करता है, और कई नवीन डेटाबेस सिस्टम (उदाहरण: MongoDB BSON का Date प्रकार) भी मिलीसेकंड संग्रहित करते हैं।

नतीजा एक चिरंतन भाषा-पार बग है: एक Go बैकएंड JSON फ़ील्ड में 1700000000 (सेकंड) लिखता है; एक Node.js क्लाइंट उसे new Date(1700000000) में पास कर देता है-लेकिन JavaScript मिलीसेकंड अपेक्षित करता है, इसलिए परिणामी तिथि 2023 के अंत के बजाय 1970-01-20 बनती है। समाधान new Date(1700000000 * 1000) है। उल्टा करें: एक JS मिलीसेकंड टाइमस्टैम्प को Python के datetime.fromtimestamp() में डालिए और लगभग 55895 साल आ जाएगा। Stack Overflow पर «JavaScript Date showing 1970» के दर्जनों रूपांतर हैं, और अधिकांश में मूल कारण यही बेमेल है।

यह कन्वर्टर एक heuristic लागू करता है: यदि इनपुट 1,000,000,000,000 से बड़ा है, इसे मिलीसेकंड मानें; अन्यथा सेकंड। यह काम करता है क्योंकि 1e12 सेकंड वर्ष 33658 ईस्वी होगा (किसी भी वास्तविक सेकंड-स्केल इनपुट से कहीं परे), जबकि 1e12 मिलीसेकंड 9 सितंबर 2001 UTC है (आधुनिक रेंज के भीतर)। कुछ वैज्ञानिक सिस्टम और Linux कर्नेल APIs में उपयोग होने वाले माइक्रोसेकंड और नैनोसेकंड टाइमस्टैम्प सीमा को और ऊपर धकेलेंगे-उनके लिए सटीकता स्पष्ट रूप से निर्दिष्ट करनी होगी।

2038 की समस्या («Y2K38»)

32-बिट सहचिह्न पूर्णांक −2,147,483,648 से +2,147,483,647 तक मान संग्रहित कर सकता है। 1970-01-01 UTC से सेकंडों के रूप में व्याख्या करने पर अधिकतम निरूपित क्षण मंगलवार, 19 जनवरी 2038, 03:14:07 UTC है। एक सेकंड बाद, काउंटर ओवरफ़्लो होकर सबसे ऋणात्मक मान पर लौट जाता है, जो शुक्रवार, 13 दिसंबर 1901, 20:45:52 UTC के रूप में डिकोड होता है। कोई भी 32-बिट चौड़ा time_t, कोई भी डेटाबेस कॉलम जो समय के लिए 4-बाइट सहचिह्न पूर्णांक संग्रहित करता है, और कोई भी एम्बेडेड सिस्टम जिसका फ़र्मवेयर लगभग 2010 से पहले लिखा गया है, ख़तरे में है।

उजागर सतह असुविधाजनक है: 15-30 वर्षों के परिनियोजन-जीवनचक्र वाले औद्योगिक PLC और SCADA नियंत्रक जो आज भी स्थापित किए जा रहे हैं; पुराने MySQL TIMESTAMP कॉलम जिनका दस्तावेज़ कहता है कि वे 2038 की सीमा पर संतृप्त होते हैं; ext3 फ़ाइलसिस्टम; 4-बाइट टाइमस्टैम्प पैक करने वाले बाइनरी प्रोटोकॉल प्रारूप (DNSSEC RRSIG फ़ील्ड, NTPv3, कई औद्योगिक फ़ील्डबस); पुराने 32-बिट Linux कर्नेल पर चुपचाप चलने वाली स्मार्ट टीवी और ऑटोमोटिव इन्फ़ोटेनमेंट। मुख्य धारा का समाधान time_t को 64-बिट तक चौड़ा करना है, जो अधिकतम को लगभग +292 अरब वर्ष तक बढ़ा देता है-सूर्य की ऊष्मीय मृत्यु के पार। Linux 5.6 (मार्च 2020) ने Arnd Bergmann के y2038 patchset के ज़रिए सभी 32-बिट आर्किटेक्चर में 64-बिट टाइम syscalls जोड़े; glibc 2.34 (अगस्त 2021) ने 64-बिट time_t को _TIME_BITS=64 के ज़रिए opt-in बनाया; Debian 13 «Trixie» (2025) पूरा संग्रह पुनः-संकलित करने वाला पहला रिलीज़ है। Apple ने macOS 10.15 (2019) और iOS 11 (2017) में 32-बिट बाइनरी को deprecated किया, इसलिए उपभोक्ता बेड़ा प्रभावी रूप से प्रतिरक्षित है।

बचा हुआ जोखिम क्षेत्र भारी रूप से एम्बेडेड और डिस्क पर लीगेसी डेटा है: एक 64-बिट कर्नेल जो किसी लीगेसी डेटाबेस से 32-बिट टाइमस्टैम्प कॉलम पढ़ रहा है, ख़ुद डेटाबेस की तरह ही टूटा हुआ है। माइग्रेशन प्रति-एप्लिकेशन डेटा-फ़ॉर्मैट समस्या है, केवल कर्नेल समस्या नहीं।

JavaScript Date-क्षेत्र की सबसे अभिशप्त API

JavaScript का Date ऑब्जेक्ट मई 1995 में Java 1.0 से थोक में नक़ल किया गया था, उस 10-दिन की sprint के दौरान जब Brendan Eich ने मूल LiveScript लिखा। Java ने ख़ुद JDK 1.1 (1997) में java.util.Date की अधिकांश विधियों को deprecated किया, पर JavaScript ने उन्हें विरासत में पाया और web संगतता तोड़ नहीं सकता था, इसलिए वे टिकी हुई हैं। नतीजा एक ऐसी API है जहाँ:

महीने 0-इंडेक्स्ड हैं (new Date(2024, 0, 15) = 15 जनवरी) पर दिन 1-इंडेक्स्ड हैं।
getYear() «वर्ष माइनस 1900» लौटाता है-2024 के लिए getYear() 124 है। getFullYear() बाद में जोड़ा गया जो सीधे 2024 लौटाता है।
Date.parse('2024-03-15') UTC आधी रात के रूप में पार्स होता है; Date.parse('2024/03/15') स्थानीय आधी रात है; Date.parse('March 15, 2024') कार्यान्वयन-परिभाषित है।
ECMAScript 5 (दिसंबर 2009) से पहले पार्सिंग लगभग पूरी तरह कार्यान्वयन-परिभाषित थी-वही इनपुट स्ट्रिंग IE, Firefox, Chrome और Safari पर अलग-अलग Date मान दे सकती थी।

Temporal API (मार्च 2021 से TC39 Stage 3) आधुनिक प्रतिस्थापन है, जो Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime और एक असली Temporal.Duration प्रकार प्रदान करता है। ब्राउज़र समर्थन तैनात हो रहा है (Firefox Nightly, Safari 18 आंशिक, 2024 तक Chrome flag के पीछे); polyfills काम करते हैं पर लगभग 25 KB जोड़ते हैं। Moment.js को इसके अनुरक्षकों ने सितंबर 2020 में रखरखाव मोड में डाल दिया-2026 में नए प्रोजेक्टों के लिए सिफ़ारिश है यदि ब्राउज़र समर्थन हो तो Temporal पहले, अन्यथा Luxon या date-fns, Moment.js कभी नहीं।

आप यह कब उठाएँगे

API प्रतिक्रियाओं की डीबगिंग। अधिकांश JSON APIs टाइमस्टैम्प को या तो Unix पूर्णांकों के रूप में या ISO 8601 स्ट्रिंगों के रूप में लौटाती हैं-और कई दोनों मिलाती हैं। दिन में दर्जनों बार एक संख्या को कन्वर्टर में चिपकाना सबसे बड़ा उपयोग-मामला है।
लॉग फ़ाइल विश्लेषण। syslog, journald, AWS CloudWatch और अधिकांश एप्लिकेशन लॉग Unix सेकंडों में टाइमस्टैम्प होते हैं। इंजीनियर एक लॉग पंक्ति से टाइमस्टैम्प कॉपी करते हैं और दीवार-घड़ी समकक्ष जानना चाहते हैं।
डेटाबेस तिथि-कॉलम निरीक्षण। एक एक-बार की psql या mysql क्वेरी 1700000000 लौटाती है; डेटाबेस के पास FROM_UNIXTIME() जैसे फ़ंक्शन हैं पर ब्राउज़र उपकरण ad hoc काम के लिए तेज़ है।
JWT निरीक्षण। एक OAuth टोकन को डिकोड करने पर "exp": 1738367200 दिखता है। क्या यह टोकन समाप्त हो गया है? कब समाप्त होता है? टाइमस्टैम्प कन्वर्टर सबसे तेज़ उत्तर है।
ब्लॉकचेन टाइमस्टैम्प। Bitcoin का ब्लॉक nTime Unix सेकंड में है (2106 में ओवरफ़्लो, 4-बाइट unsigned)। Ethereum ब्लॉक टाइमस्टैम्प भी Unix सेकंड में हैं।
OS फ़ाइल-सिस्टम मेटाडेटा। ls -l --time-style=+%s Unix mtime प्रिंट करता है; stat -c '%Y' filename mtime को पूर्णांक के रूप में लौटाता है। फ़ोरेंसिक टाइमस्टैम्प मेल-जोल अक्सर मैन्युअल डिकोडिंग में आता है।
प्रमाणपत्र notBefore / notAfter और HTTP If-Modified-Since हेडर-सभी ऐसे टाइमस्टैम्प हैं जिन्हें कभी-कभी डिकोड करना पड़ता है।

लीप-सेकंडों पर एक टिप्पणी

1972 से, UTC में 27 लीप सेकंड डाले गए हैं ताकि दीवार-घड़ी समय को पृथ्वी की धीमी होती घूर्णन के साथ संरेखित रखा जा सके। सबसे हाल का 31 दिसंबर 2016, 23:59:60 UTC था। Unix समय लीप सेकंडों को एन्कोड नहीं करता-POSIX स्पष्ट रूप से कहता है कि एक Unix टाइमस्टैम्प मान लेता है कि हर दिन ठीक 86,400 सेकंडों का है। पुराने Linux सिस्टम अंतिम सेकंड को «दोहराते» हैं; Google और AWS «leap smear» का उपयोग करते हैं जो अतिरिक्त सेकंड को 24-घंटे की खिड़की पर फैलाता है। किसी भी तरह, Unix समय भंडारण में कभी 23:59:60 नहीं पढ़ता, और दो टाइमस्टैम्पों को घटाने पर जो एक लीप सेकंड को पार करते हैं, उत्तर वास्तविक SI-सेकंड बीते समय से एक सेकंड कम आता है। एप्लिकेशन कोड के लिए यह अदृश्य है। खगोलीय या वित्तीय-ट्रेडिंग सॉफ़्टवेयर के लिए यह मायने रख सकता है। नवंबर 2022 में, 27वें General Conference on Weights and Measures ने 2035 तक लीप सेकंडों का सम्मिलन रोकने के लिए मतदान किया, उन्हें कहीं बड़े समय-समय पर समायोजन से बदलते हुए।

त्वरित संदर्भ

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's `nTime` limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

और सवाल

वही टाइमस्टैम्प मेरे मित्र की मशीन पर अलग समय क्यों दिखाता है?

क्योंकि अंतर्निहित संख्या UTC है, पर डिस्प्ले स्थानीय समय में परिवर्तित कर देता है। 1700000000 22:13:20 UTC है-पर न्यूयॉर्क में 17:13:20 और सिडनी में अगले दिन 06:13:20। संख्या वही है; केवल रेंडरिंग भिन्न है। समय-क्षेत्र भ्रम को बाहर करने के लिए दोनों मशीनों को UTC में दिखाने के लिए कहें।

Y2K और Y2K38 में क्या अंतर है?

Y2K (वर्ष 2000) एप्लिकेशन कोड में एक तर्क समस्या थी: कई सिस्टम वर्षों को दो ASCII अंकों के रूप में संग्रहित करते थे, इसलिए «00» 1900 और 2000 के बीच अस्पष्ट हो जाता था। हर एप्लिकेशन की अलग-अलग जाँच और पैच करनी पड़ी; कुल विश्वव्यापी सुधार खर्च 300-600 बिलियन डॉलर अनुमानित था। Y2K38 ज़्यादातर निम्न-स्तरीय पुस्तकालयों में डेटा-प्रकार समस्या है-C लाइब्रेरी और कर्नेल को 64-बिट time_t के विरुद्ध फिर से संकलित करना उनके विरुद्ध लिंक करने वाले हर एप्लिकेशन के लिए सतह के एक बड़े हिस्से को ठीक कर देता है। बचे हुए कठिन मामले डिस्क पर बने रहने वाले डेटा हैं (डेटाबेस, फ़ाइल मेटाडेटा, बाइनरी प्रोटोकॉल) जिन्हें डेटा-माइग्रेशन टूलिंग चाहिए। पारंपरिक ज्ञान यह है कि 2038, 2000 की तुलना में छोटा और कम सुर्ख़ी बनने वाला कार्यक्रम होगा-अधिक स्थानीयकृत एम्बेडेड-डिवाइस विफलताएँ, कम सुर्ख़ी आउटेज।

new Date('2024-03-15') कभी-कभी 14 मार्च क्यों दिखाता है?

क्योंकि वह स्ट्रिंग ES5 मानक के अनुसार UTC आधी रात के रूप में पार्स होती है, और फिर आपके स्थानीय समय-क्षेत्र में दिखाई जाती है। US Pacific जैसे UTC-8 क्षेत्र में, 15 मार्च की UTC आधी रात स्थानीय समय में 14 मार्च के दोपहर 4 बजे है, इसलिए .getDate() 14 लौटाता है। आधुनिक कोड में सुधार है या तो new Date('2024-03-15T12:00:00') (Z छोड़ने पर JavaScript इसे स्थानीय दोपहर के रूप में पार्स करता है) या, बेहतर, Temporal.PlainDate.from() API जब वह उपलब्ध हो जाए।

क्या कुछ सर्वर पर भेजा जाता है?

नहीं। रूपांतरण आपके ब्राउज़र में स्थानीय रूप से चलने वाला JavaScript अंकगणित है। आप जो टाइमस्टैम्प दर्ज करते हैं उनके बारे में कुछ भी पृष्ठ से बाहर नहीं जाता-यह उपयोगी है जब मान ग्राहक ID, आंतरिक लॉग पंक्तियाँ, या सत्र डीबग डेटा हों जिन्हें आप कहीं अपलोड नहीं करना चाहते। पृष्ठ लोड होने के बाद ऑफ़लाइन भी काम करता है।