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

यह कैसे काम करता है

सब कुछ ब्राउज़र के Date ऑब्जेक्ट से होकर गुज़रता है, जो इंटरनली सिर्फ़ एक नंबर स्टोर करता है: Unix एपॉक यानी 1 जनवरी 1970 की UTC आधी रात से मिलीसेकंड। किसी टाइमस्टैंप को कन्वर्ट करने पर, अगर आपने सेकंड बताया है तो टूल उसे 1,000 से गुणा करता है, एक Date बनाता है, फिर उसे चार तरीकों से दिखाता है: toLocaleString के ज़रिए आपका लोकल टाइम (ब्राउज़र का Intl फ़ॉर्मैटर, आपकी अपनी टाइमज़ोन और भाषा इस्तेमाल करते हुए), UTC, ISO 8601, और एक रिलेटिव लेबल जैसे "3 दिन में / 2 घंटे पहले" जो अभी के फ़र्क़ को साल, महीने, दिन, घंटे, मिनट, या सेकंड में बांटकर कैलकुलेट होता है।

दूसरी तरफ़, डेट पिकर की वैल्यू को लोकल टाइम के रूप में पार्स करके वापस सेकंड और मिलीसेकंड दोनों में कन्वर्ट किया जाता है। datetime-local फ़ील्ड को पहले टाइमस्टैंप को आपके टाइमज़ोन ऑफ़सेट से शिफ़्ट करके फ़ीड किया जाता है, जो वह पेचीदा हिस्सा है जिसे ज़्यादातर कन्वर्टर सूक्ष्म रूप से ग़लत कर देते हैं: toISOString() हमेशा UTC में बात करता है, इसलिए उस शिफ़्ट के बिना पिकर आपकी उम्मीद से घंटों दूर का समय दिखाएगा।

जो क्लासिक गलती से यह टूल यूनिट को स्पष्ट बनाकर बचाता है: सेकंड बनाम मिलीसेकंड। मौजूदा Unix टाइम सेकंड में 10 अंकों का और मिलीसेकंड में 13 अंकों का होता है। किसी मिलीसेकंड वैल्यू को सेकंड मानकर पार्स करें तो आप 50,000+ साल आगे भविष्य में पहुंच जाते हैं; उलटा करें तो जनवरी 1970 मिलता है। अगर कोई कन्वर्ज़न अजीब लगे, यूनिट ड्रॉपडाउन बदल दें, लगभग हमेशा यही पूरी गड़बड़ होती है। रेंज से बाहर की वैल्यू (JavaScript डेट्स एपॉक के हर तरफ़ 10 करोड़ दिनों तक सीमित हैं, यानी लगभग साल 275760) एक साफ़ एरर देती हैं, बकवास आउटपुट नहीं।

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