टाउको दुखाइबिना Unix टाइमस्ट्याम्प
तीनजना डेभलपरलाई अहिले कति बजेको छ भनी सोध्नुहोस् र तिनी कहाँ बसेका छन् भन्नेमा भर परेर तपाईंले तीनवटा फरक जवाफ पाउन सक्नुहुन्छ। Unix टाइमस्ट्याम्पलाई सोध्नुहोस् भने तपाईं ठ्याक्कै एउटा नम्बर पाउनुहुन्छ, पृथ्वीका सबैका लागि उही। त्यो एउटै इन्टिजरले नै एपोक टाइमलाई तपाईंले कहिल्यै छुने लगभग हरेक लग फाइल, डाटाबेस पङ्क्ति, र API जवाफको आधार बनाउँछ। यो पेजले त्यो नम्बरको अर्थ के हो, यसलाई दुवै दिशामा कसरी पढ्ने, र यसले प्रायः कहाँ अलमल्याउँछ भनी व्याख्या गर्छ।
Unix समय वास्तवमा के हो
Unix टाइमस्ट्याम्प 1 जनवरी 1970 UTC 00:00:00 देखि बितेका सेकेन्डको संख्या हो, लिप सेकेन्ड नगणना गरी। त्यो क्षणलाई एपोक भनिन्छ, र यसलाई शुरुका Unix इन्जिनियरहरूले केवल गन्न सुविधाजनक गोलाकार मिति भएकाले छानेका थिए। एपोकमा मान ठ्याक्कै 0 हो। त्यसयताको हरेक सेकेन्डले एक थप्छ, त्यसैले नम्बर केवल बढ्दै जान्छ। 1970 भन्दा अघिका मितिहरू पनि पूर्णतया मान्य छन्, ऋणात्मक इन्टिजरका रूपमा व्यक्त गरिएका।
तपाईंले यो अवधारणालाई POSIX time वा, ढिलो रूपमा, एपोक टाइम पनि भनिएको देख्नुहुनेछ। लेबल जे भए पनि, मेकानिक्स उही हुन्: सेकेन्डको एउटा सधैं बढिरहने काउन्टर। यो फर्म्याट गरिएको स्ट्रिङभन्दा सादा इन्टिजर भएकाले, कम्प्युटरले यसलाई केही बाइटमा भण्डारण गर्न सक्छ र एउटा घटाउ गरेर दुईवटा तुलना गर्न सक्छ।
सेकेन्ड, मिलिसेकेन्ड, र साथीहरू
क्लासिक Unix समयले सम्पूर्ण सेकेन्ड गन्छ, जसले आज तपाईंले देख्ने परिचित दस-अंकको नम्बर दिन्छ। तर धेरै वातावरणलाई सूक्ष्म रिजोल्युसन चाहिन्छ। उदाहरणका लागि, JavaScript मिलिसेकेन्डमा काम गर्छ, तेह्र-अंकको मान उत्पादन गर्दै, र केही प्रणालीहरू माइक्रोसेकेन्ड वा न्यानोसेकेन्डसम्म पुग्छन्। एउटा भरपर्दो अंगुठाको नियम: दस-अंकको नम्बर सेकेन्ड हो, तेह्र अंक मिलिसेकेन्ड हो। तपाईंको रूपान्तरित मिति तपाईंले वर्तमान दिन अपेक्षा गर्दा 1970 वरपर कतै आइपुग्छ भने, तपाईंले लगभग निश्चित रूपमा मिलिसेकेन्डलाई सेकेन्ड फिल्डमा दिनुभएको छ, वा उल्टो। हाम्रो रूपान्तरकले परिमाण स्वतः पत्ता लगाउँछ, त्यसैले तपाईंले विरलै अनुमान लगाउनुपर्छ।
डेभलपरहरूले यसमा किन भर पर्छन्
ठूलो फाइदा भनेको टाइमस्ट्याम्प टाइमजोन-न्युट्रल हुनु हो। इन्टिजर 1735689600 ले टोकियो, बर्लिन, र साओ पाउलोमा उही क्षणलाई जनाउँछ। फर्म्याट गरिएको स्थानीय स्ट्रिङको सट्टा त्यो नम्बर भण्डारण गर्नाले तपाईंलाई कुनै मान कुन घडीको हो भनी कहिल्यै अलमल हुँदैन। क्रमबद्ध गर्नु पनि सजिलो हुन्छ, किनभने कालानुक्रमिक क्रम केवल संख्यात्मक क्रम हो, त्यसैले टाइमस्ट्याम्प स्तम्भमाथिको डाटाबेस इन्डेक्सले घटनाहरूलाई कुनै पार्सिङ बिना नै सही रूपमा क्रमबद्ध गर्छ। अंकगणित पनि उत्तिकै सफा छ: दुई घटनाबीचको अन्तर एउटा घटाउ हो, र एक दिन थप्नु 86400 थप्नु मात्र हो। यी गुणहरू नै ठ्याक्कै लग, टोकन, क्यास, र मेसेज कतारहरूले एपोक टाइमतिर जानुको कारण हुन्।
दुवैतिर रूपान्तरण
टाइमस्ट्याम्पबाट मानिसले पढ्न मिल्ने मितितिर जानु भनेको सेकेन्डको गणनालाई क्यालेन्डरमाथि प्रोजेक्ट गर्नु, त्यसपछि तपाईंले वास्ता गर्ने जुनसुकै टाइमजोनमा त्यसलाई फर्म्याट गर्नु हो। अर्कोतिर जानु, तपाईंले वर्ष, महिना, दिन, र समय लिनुहुन्छ, त्यो मिति कुन टाइमजोनमा व्यक्त गरिएको हो भनी निर्णय गर्नुहुन्छ, र यसलाई एपोकदेखिको सेकेन्डमा फर्काउनुहुन्छ। हाम्रो टुलले दुवै दिशा तुरुन्तै र पूर्णतया तपाईंको ब्राउजरमै गर्छ, त्यसैले तपाईंले पेस्ट गर्ने कुनै पनि कुरा तपाईंको मेसिन छोड्दैन। डिकोड गर्न नम्बर पेस्ट गर्नुहोस्, वा इन्कोड गर्न मिति छान्नुहोस्, र उही क्षणमा UTC र तपाईंको स्थानीय समय दुवैमा परिणाम पढ्नुहोस्।
UTC बनाम स्थानीय समय, क्लासिक जाल
टाइमस्ट्याम्प आफैंमा कुनै टाइमजोन हुँदैन; यो सधैं UTC मा एङ्कर गरिएको हुन्छ। भ्रम केवल तपाईंले यसलाई प्रदर्शन गर्दा मात्र देखा पर्छ। तपाईंले 1700000000 रूपान्तरण गर्नुभयो र तपाईंको स्क्रिनले साँझको समय देखाउँछ भने तपाईंको अर्को देशको सहकर्मीले दिउँसोको समय देख्छ, केही पनि बिग्रिएको छैन, तपाईं दुवैले फरक-फरक स्थानीय घडीमा प्रस्तुत गरिएको उही क्षण हेर्दै हुनुहुन्छ। बगहरू तब देखा पर्छन् जब कोडले स्थानीय मितिलाई UTC भए झैं पढ्छ, वा अफसेट रेकर्ड नगरी वाल-क्लक समय स्ट्याम्प गर्छ। सुरक्षित बानी भनेको UTC भण्डारण गर्नु र प्रसारण गर्नु हो, र केवल अन्तिम क्षणमा मात्र स्थानीय अफसेट लागू गर्नु हो, जब तपाईं मान कुनै व्यक्तिलाई देखाउनुहुन्छ। शंका लागेमा, आफ्नो स्थानीय लाइनको सट्टा रूपान्तरकको UTC लाइनसँग तुलना गर्नुहोस्।
वर्ष 2038 समस्या
धेरै पुराना प्रणालीहरूले Unix समयलाई साइन गरिएको 32-बिट इन्टिजरमा भण्डारण गरे। त्यो फिल्ड 19 जनवरी 2038 का दिन UTC 03:14:07 पछि एक सेकेन्डमा ठाउँ सकिन्छ, जब काउन्टर ओभरफ्लो हुन्छ र ऋणात्मक नम्बरमा फर्कन्छ, सम्भवतः मितिहरूलाई 1901 सम्म फिर्ता फ्याँक्दै। यो Y2K जस्तै समस्याको परिवार हो। राम्रो कुरा भनेको आधुनिक अपरेटिङ प्रणाली र भाषाहरू धेरैजसो 64-बिट टाइमस्ट्याम्पमा सरेका छन्, जुन लगभग 292 अरब वर्षसम्म ओभरफ्लो हुँदैन, त्यसैले नयाँ कोडका लागि यो आपत्कालीन कुराभन्दा जान्नुपर्ने ऐतिहासिक कौतुहलता मात्र हो।
थप ब्राउजर-आधारित सहयोगीहरूका लागि हाम्रा डेभलपर टुलहरू हेर्नुहोस्, र तपाईंलाई नम्बरहरूमा नै काम गर्न आवश्यक भए, क्यालकुलेटरहरू एक क्लिक टाढा छन्।
बारम्बार सोधिने प्रश्नहरू
Unix टाइमस्ट्याम्प के हो?
यो 1 जनवरी 1970 UTC 00:00:00 देखिको सेकेन्डको संख्या हो, लिप सेकेन्ड नगणना गरी। त्यो सुरुवात क्षणलाई एपोक भनिन्छ, र गणना समयसँगै मात्र बढ्छ।
मेरो नम्बर किन 1970 नजिकको मितिमा रूपान्तरण हुन्छ?
तपाईंले सम्भवतः सेकेन्ड र मिलिसेकेन्ड गडमड गर्नुभयो। दस-अंकको नम्बर सेकेन्ड हो र तेह्र-अंकको नम्बर मिलिसेकेन्ड हो। मिलिसेकेन्डलाई सेकेन्ड फिल्डमा दिँदा देखिने समय लगभग हजारले भाग हुन्छ, तपाईंलाई एपोक नजिक ल्याउँदै।
Unix टाइमस्ट्याम्पको टाइमजोन हुन्छ?
होइन। मान सधैं UTC मा एङ्कर गरिएको हुन्छ। तपाईंले टाइमस्ट्याम्पलाई मानिसले पढ्न मिल्ने मितिका रूपमा प्रदर्शन गर्दा मात्र टाइमजोन तस्बिरमा आउँछ, जुन कारणले नै उही नम्बरले फरक-फरक व्यक्तिलाई फरक-फरक वाल-क्लक समय देखाउन सक्छ।
मितिलाई फेरि टाइमस्ट्याम्पमा कसरी रूपान्तरण गर्ने?
वर्ष, महिना, दिन, र समय दिनुहोस्, त्यो मिति कुन टाइमजोनमा व्यक्त गरिएको हो भनी निर्णय गर्नुहोस्, र टुलले यसलाई एपोकदेखिको सेकेन्डमा फर्काउँछ। तपाईं यो पेजमा तुरुन्तै तपाईंको ब्राउजरमै दुवै दिशा गर्न सक्नुहुन्छ।
वर्ष 2038 समस्या के हो?
Unix समयलाई साइन गरिएको 32-बिट इन्टिजरमा भण्डारण गर्ने प्रणालीहरू 19 जनवरी 2038 UTC 03:14:07 पछि एक सेकेन्डमा ओभरफ्लो हुन्छन्। आधुनिक 64-बिट टाइमस्ट्याम्पले यसलाई अर्बौं वर्षसम्म बेवास्ता गर्छ, त्यसैले धेरैजसो हालको सफ्टवेयर प्रभावित हुँदैन।
मेरो डेटा सर्भरमा पठाइन्छ?
होइन। रूपान्तरण पूर्णतया तपाईंको ब्राउजरभित्रै हुन्छ, त्यसैले तपाईंले पेस्ट गर्ने कुनै पनि टाइमस्ट्याम्प वा मिति तपाईंकै उपकरणमा रहन्छ।