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

Unix टाइमस्टैम्प 1970-01-01 00:00:00 UTC के बाद से बीते सेकंड (या मिलीसेकंड) की गिनती है — वही epoch जिसे Linux, macOS, डेटाबेस, लॉग फ़ाइलें और HTTP हेडर इस्तेमाल करते हैं। यह टूल उस संख्यात्मक मान और पढ़ने योग्य तारीख़ के बीच UTC व आपके लोकल टाइमज़ोन दोनों में दोतरफ़ा बदलता है, और अंक-संख्या से सेकंड/मिलीसेकंड पहचान लेता है।

उदाहरण

इनपुट (सेकंड, 10 अंक):

1709251200

आउटपुट:

UTC (ISO 8601)   2024-03-01T00:00:00.000Z
Local time       3/1/2024, 9:00:00 AM     (in a UTC+9 locale)
Relative         2 months ago             (relative to now)
Seconds          1709251200
Milliseconds     1709251200000

वही पल मिलीसेकंड में 1709251200000 होगा — 13 अंक।

मेरा टाइमस्टैम्प ग़लत वर्ष क्यों दिखा रहा है?

• सेकंड बनाम मिलीसेकंड गड़बड़। 1709251200 को मिलीसेकंड मानें तो जनवरी 1970 मिलता है; 1709251200000 को सेकंड मानें तो वर्ष 56137। अंक गिनें — 10 अंक सेकंड, 13 अंक मिलीसेकंड।
• माइक्रोसेकंड या नैनोसेकंड। कुछ सिस्टम (Python का time.time_ns(), Prometheus) 16 या 19 अंकीय मान देते हैं। पेस्ट करने से पहले 1000 या 1,000,000 से भाग दें।
• टाइमज़ोन का भ्रम। लोकल पंक्ति UTC से आपके ब्राउज़र के ऑफ़सेट जितनी अलग होती है। यदि लॉग में 12:00:00 है और साइट पर 21:00:00 दिखता है, तो यह UTC+9 है, बग नहीं।
• 32-बिट ओवरफ्लो (Y2038)। समय को signed int32 में रखने वाले पुराने सिस्टम 2147483647 (19 जनवरी 2038 UTC) पर नेगेटिव में बदल जाते हैं और उसे 1901 मान लेते हैं।
• आगे के शून्य कट गए। 0012345 बनकर 12345 रह जाता है। मान को बिना रीफ़ॉर्मेट किए, जैसा है वैसा ही पेस्ट करें।
• फ़्लोट टाइमस्टैम्प। 1709251200.123 दशमलव वाला सेकंड है। टूल इसे स्वीकार कर लेता है और दशमलव हिस्से को मिलीसेकंड के रूप में रखता है।

मेरा टाइमस्टैम्प सेकंड में है या मिलीसेकंड में?

अंक गिनें। लगभग 2001 से 2286 के बीच की तारीख़ के लिए सेकंड में 10 अंक (जैसे 1709251200) और मिलीसेकंड में 13 अंक (जैसे 1709251200000) होते हैं। तीन शून्य पर ख़त्म होने वाला बड़ा नंबर लगभग निश्चित रूप से मिलीसेकंड है। यह टूल परिमाण से स्वतः पहचान करता है: 10^12 या अधिक मान मिलीसेकंड माने जाते हैं।

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

साइन्ड 32-बिट इंटीजर में रखे Unix टाइमस्टैम्प 19 जनवरी 2038 को 03:14:07 UTC, यानी 2147483647 पर ओवरफ्लो हो जाते हैं। समय के लिए अब भी int32 इस्तेमाल करने वाले सिस्टम (पुराना C कोड, कुछ एम्बेडेड डिवाइस, कुछ डेटाबेस) नेगेटिव में चले जाते हैं और इसे 13 दिसंबर 1901 समझते हैं। आधुनिक 64-बिट सिस्टम और JavaScript नंबर सुरक्षित हैं।

मेरा टाइमस्टैम्प ग़लत वर्ष क्यों दिखा रहा है?

लगभग हमेशा इकाई का बेमेल होता है। यदि आप 1709251200000 पेस्ट करें और टूल उसे सेकंड माने, तो 56137 के आसपास की तारीख़ मिलेगी। यदि 1709251200 पेस्ट करें और टूल उसे मिलीसेकंड माने, तो 20 जनवरी 1970 मिलेगा। इकाई ड्रॉपडाउन स्पष्ट रूप से सेट करें या अंक गिनें।

क्या टाइमस्टैम्प में टाइमज़ोन शामिल होता है?

नहीं। Unix टाइमस्टैम्प 1970-01-01 00:00:00 UTC से सेकंड की पूर्ण गिनती है — इसमें टाइमज़ोन नहीं होता। यह टूल UTC रूप और आपके ब्राउज़र के लोकल-टाइम रूप दोनों दिखाता है। सहयोगी से 9 घंटे का अंतर टाइमज़ोन का अंतर है, बग नहीं।

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

हाँ। नेगेटिव मान समर्थित हैं — जैसे -86400, 31 दिसंबर 1969 UTC है। सभी सिस्टम इसे नहीं लेते (कुछ डेटाबेस और पुरानी भाषाएँ शून्य पर सीमित कर देती हैं), पर JavaScript Date इसे मूल रूप से संभालता है, इसलिए यह टूल सही बदल देगा।

क्या टाइमस्टैम्प फ़ील्ड में ISO 8601 तारीख़ स्ट्रिंग काम करती है?

नहीं, टाइमस्टैम्प फ़ील्ड केवल संख्यात्मक epoch मान लेता है। कैलेंडर तारीख़ चुनने के लिए "तारीख़ → टाइमस्टैम्प" अनुभाग का उपयोग करें। 2024-03-01T00:00:00Z जैसी ISO 8601 स्ट्रिंग है तो ब्राउज़र कंसोल में new Date("...").getTime() से मिलीसेकंड लें, या तारीख़ पिकर में पेस्ट करें।

क्या आप मेरी बदली हुई टाइमस्टैम्प/तारीख़ें सहेजते हैं?

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