🍤 👩🏻‍🎤 🍯 जावास्क्रिप्ट में समय क्षेत्र के साथ काम करना 👩‍❤️‍💋‍👩 🧑🏿‍🤝‍🧑🏽 🎾

हाल ही में, मैं अपनी टीम द्वारा रखे गए जेएस कैलेंडर लाइब्रेरी में टाइम ज़ोन जोड़ने के काम पर काम कर रहा था। मुझे जावास्क्रिप्ट में बेकार समय क्षेत्र समर्थन के बारे में अच्छी तरह से पता था, लेकिन मैं उम्मीद कर रहा था कि मौजूदा डेटा ऑब्जेक्ट्स को अमूर्त करने से अधिकांश कठिनाइयों को हल करना आसान हो जाएगा।

हालाँकि, मेरे सपने धूल गए। जब मैंने कार्य में विलंब किया, तो मैंने महसूस किया कि इस भाषा में समय क्षेत्र के साथ काम करना वास्तव में कठिन है। केवल समय प्रदर्शन को प्रारूपित करने और जटिल परिचालनों (कैलेंडर फ़ंक्शन) का उपयोग करके तिथि की गणना करने की तुलना में कुछ अधिक जटिल लागू करना बेहद कठिन था। मुझे इस समस्या को हल करने में मूल्यवान अनुभव प्राप्त हुआ, और इसने नई कठिनाइयों को जन्म दिया।

इस लेख में मैं इस बात पर चर्चा करना चाहता हूं कि मेरे पास क्या था और यह कैसे हल हुआ। जब मैं पाठ लिख रहा था, मैंने महसूस किया कि सभी कठिनाइयों का कारण समय क्षेत्र के विषय में मेरी खराब समझ थी। इस जागरूकता के प्रकाश में, मैंने पहले परिभाषा और मानकों के बारे में विस्तार से बात करने का प्रस्ताव रखा, और उसके बाद ही जावास्क्रिप्ट पर आगे बढ़ा।

एक समय क्षेत्र क्या है?

एक समय क्षेत्र एक भौगोलिक क्षेत्र है जो सरकार द्वारा निर्धारित स्थानीय समय का उपयोग करता है। कई देश पूरी तरह से किसी विशेष समय क्षेत्रों से संबंधित हैं, और बड़े राज्यों के क्षेत्रों में, जैसे कि रूस और यूएसए, कई समय क्षेत्रों का उपयोग किया जाता है। यह उत्सुक है कि हालांकि चीन भी काफी बड़ा है, यह केवल एक समय क्षेत्र को स्वीकार करता है। कभी-कभी यह अजीब परिस्थितियों की ओर जाता है जब देश के पश्चिमी भाग में सूर्योदय सुबह 10 बजे के आसपास शुरू होता है।

GMT, UTC और ऑफसेट

जीएमटी

स्थानीय दक्षिण कोरियाई समय GMT+09:00 रूप में नामित किया गया है। GMT का अर्थ ग्रीनविच मीन टाइम (GMT) है, जो कि इस बार ग्रीनविच, ब्रिटेन में रॉयल ऑब्जर्वेटरी की घड़ी पर है। यह प्राइम मेरिडियन पर स्थित है। GMT- सिस्टम रेडियो सिग्नल का प्रसारण 5 फरवरी, 1924 को शुरू हुआ और यह 1 जनवरी, 1972 को विश्व मानक में बदल गया।

यूटीसी

बहुत से लोग सोचते हैं कि जीएमटी और यूटीसी एक ही चीज हैं, अक्सर उन्हें विनिमेय प्रणाली के रूप में उपयोग किया जाता है। लेकिन यह एक गलती है। UTC प्रणाली 1972 में पृथ्वी के घूमने के प्रभाव की भरपाई करने के तरीके के रूप में दिखाई दी। प्रणाली अंतर्राष्ट्रीय परमाणु समय पर आधारित है, इसकी गणना सीज़ियम परमाणुओं के विद्युत चुम्बकीय कंपन की आवृत्ति द्वारा की जाती है। दूसरे शब्दों में, UTC GMT के लिए अधिक सटीक प्रतिस्थापन है। यद्यपि दोनों प्रणालियों के बीच वास्तविक समय का अंतर बहुत कम है, लेकिन सॉफ्टवेयर डेवलपर्स के लिए UTC पर भरोसा करना बेहतर है।

एक दिलचस्प तथ्य: जब UTC अभी भी विकसित किया जा रहा था, तो इसे CUT (कोऑर्डिनेटेड यूनिवर्सल टाइम) नाम देने के लिए अंग्रेजी बोलने वाले देशों में, और फ्रेंच-भाषी देशों में - TUC (टेम्प्स यूनिवर्सल कोऑर्डन) का नाम दिया गया था। हालांकि, शिविरों में से कोई भी जीत नहीं सका, और वे प्रस्तावित विकल्पों (सी, टी और यू) दोनों से वर्तनी, सिस्टम यूटीसी को कॉल करने के लिए सहमत हुए।

विस्थापन

+09:00 में UTC+09:00 मतलब है कि स्थानीय समय मानक यूटीसी समय से 9 घंटे आगे है। यही है, जब यह दक्षिण कोरिया में रात 9 बजे है, तो यह यूटीसी क्षेत्र में दोपहर है। यूटीसी समय और स्थानीय समय के बीच के अंतर को "ऑफसेट" कहा जाता है, जिसे सकारात्मक या नकारात्मक मूल्यों के रूप में व्यक्त किया जाता है: +09:00 , -03:00 , आदि।

कई देशों में, यह आपके समय क्षेत्र को अद्वितीय नाम देने के लिए प्रथागत है। उदाहरण के लिए, दक्षिण कोरिया के समय क्षेत्र को केएसटी (कोरिया मानक समय) कहा जाता है, इसकी भरपाई KST = UTC+09:00 । हालांकि, ऑफसेट +09:00 उपयोग न केवल दक्षिण कोरिया, बल्कि जापान, इंडोनेशिया और कई अन्य देशों द्वारा भी किया जाता है, इसलिए, ऑफसेट और बेल्ट के बीच संबंध 1: 1 के रूप में नहीं, बल्कि 1: N के रूप में व्यक्त किया जाता है। +09:00 की भरपाई वाले देशों की सूची यहां प्रस्तुत की गई है ।

कुछ ऑफ़सेट न केवल घंटों के लिए काम करते हैं। उदाहरण के लिए, उत्तर कोरिया में, मानक समय +08:30 , जबकि ऑस्ट्रेलिया में कुछ क्षेत्रों में +8:45 , +09:30 और +10:30 ।

UTC ऑफसेट की पूरी सूची यहाँ है ।

टाइमज़ोन? == ऑफ़सेट?

जैसा कि मैंने कहा, हम समय क्षेत्र के नाम (केएसटी, जेएसटी) का उपयोग विनिमेय के रूप में ऑफसेट के साथ करते हैं, उनके बीच अंतर किए बिना। लेकिन एक ही समय और किसी विशेष क्षेत्र की पारी पर विचार करना गलत होगा। इसके कई कारण हैं:

डेलाइट सेविंग टाइम (DST)

कुछ देशों में, यह शब्द अज्ञात है, लेकिन कई राज्यों में, दिन के समय की बचत का अभ्यास किया जाता है, मुख्यतः यूरोप में। इसके लिए, अंतर्राष्ट्रीय शब्द DST को अपनाया जाता है - डेलाइट सेविंग टाइम। इसका मतलब है कि गर्मियों में घड़ी को मानक मानक समय से एक घंटे आगे ले जाना।

उदाहरण के लिए, कैलिफोर्निया सर्दियों में पीएसटी (प्रशांत मानक समय) और सर्दियों में पीडीटी (प्रशांत डेलाइट समय, UTC-07:00 ) का उपयोग करता है। संयुक्त राज्य अमेरिका और कनाडा में, प्रशांत समय (पीटी, प्रशांत समय) शब्द का उपयोग उन क्षेत्रों के लिए किया जाता है जो दो समय क्षेत्रों का उपयोग करते हैं।

गर्मियों का समय कब शुरू और खत्म होता है? यह सब देश पर निर्भर करता है। उदाहरण के लिए, यूएसए और कनाडा में 2006 तक, डीएसटी का इस्तेमाल अप्रैल के पहले रविवार को दोपहर 2 बजे से और अक्टूबर के आखिरी रविवार को 12 बजे तक किया जाता था। और 2007 से, गर्मियों का समय मार्च के दूसरे रविवार को 2 रातों से और नवंबर के पहले रविवार को 2 रातों से गिनना शुरू हुआ। यूरोप में, विभिन्न देश प्रत्येक समय क्षेत्र के आधार पर डीएसटी के प्रगतिशील उपयोग का अभ्यास करते हैं।

क्या समय क्षेत्र बदल रहे हैं?

प्रत्येक देश स्वयं निर्धारित करता है कि किस समय क्षेत्र का उपयोग करना है, इसलिए स्थानीय समय किसी भी राजनीतिक और / या आर्थिक कारणों से बदल सकता है। उदाहरण के लिए, संयुक्त राज्य अमेरिका में, डीएसटी सीमाओं को 2007 में बदल दिया गया था क्योंकि जॉर्ज डब्ल्यू बुश ने 2005 में ऊर्जा नीति शुरू की थी। मिस्र और रूस दिन के समय की बचत के लिए स्विच करते थे, लेकिन 2011 से इसे छोड़ दिया है।

कुछ मामलों में, सरकार न केवल डेलाइट सेविंग टाइम बदल सकती है, बल्कि मानक समय भी। उदाहरण के लिए, पहले समोआ ने ऑफसेट UTC-10:00 उपयोग किया था, लेकिन तब उन्होंने ऑस्ट्रेलिया और न्यूजीलैंड के साथ समय के अंतर के कारण व्यापार में नुकसान को कम करने के लिए UTC+14:00 पर स्विच किया। इस निर्णय के कारण दुनिया भर के समाचार पत्रों की रिपोर्ट के अनुसार, पूरे दिन देश का जीवन बर्बाद हो गया - 30 दिसंबर, 2011।

नीदरलैंड में, 1909 के बाद से +0:19:32.13 उपयोग +0:19:32.13 गया, 1937 से देश +00:20 और 1940 से +01:00 बदल गया, तब से मुख्य समय वहां नहीं बदला।

समय क्षेत्र 1: ऑफसेट एन

तो, टाइम ज़ोन में एक या अधिक ऑफ़सेट हो सकते हैं। जो समय मानक के रूप में स्वीकार किया जाता है वह किसी विशेष देश में वर्तमान राजनीतिक और / या आर्थिक कारणों पर निर्भर करता है।

रोजमर्रा की जिंदगी में, यह मुश्किलें पैदा नहीं करता है जब तक कि आप कुछ नियमों के आधार पर इस डेटा को व्यवस्थित करने की कोशिश नहीं करते हैं। कल्पना करें कि आप किसी तरह के पूर्वाग्रह का उपयोग करके अपने स्मार्टफोन पर मानक समय निर्धारित करना चाहते हैं। यदि आप एक ऐसे क्षेत्र में रहते हैं जहाँ दिन के समय की बचत का अभ्यास किया जाता है, तो आपके स्मार्टफोन को पता होना चाहिए कि आगे और पीछे कब जाना चाहिए। यही है, आपको एक समय क्षेत्र (उदाहरण के लिए, प्रशांत समय) में मानक और गर्मियों के समय के बीच संबंध स्थापित करने की आवश्यकता है।

लेकिन यह सरल नियमों के एक जोड़े के साथ नहीं किया जा सकता है। उदाहरण के लिए, जब 2007 में संयुक्त राज्य अमेरिका में डीएसटी की शुरुआत और अंत बदल गए थे, 31 मई 2006 को इसे मानक समय के रूप में पीडीटी ( -07:00 ) और 31 मार्च, 2007 को - पीएसटी ( -08:00 ) के रूप में उपयोग किया जाना था। यह पता चला है कि एक विशिष्ट समय क्षेत्र को संदर्भित करने के लिए, आपको समय क्षेत्र में बदलाव के पूरे इतिहास या दिन के समय की बचत के समय के नियमों में बदलाव की तारीख जानने की आवश्यकता है।

आप कह सकते हैं: "न्यूयॉर्क में समय क्षेत्र पीएसटी ( -08:00 ) है।" हालांकि, इसे स्पष्ट करने की आवश्यकता है: "न्यूयॉर्क में वर्तमान समय क्षेत्र पीएसटी है।" इसके अलावा, सिस्टम के सटीक कार्यान्वयन के लिए, आपको एक और भी अधिक सटीक अभिव्यक्ति का उपयोग करने की आवश्यकता है। "समय क्षेत्र" शब्द को भूल जाइए। आपको कहना होगा: "अब न्यूयॉर्क में, पीएसटी का उपयोग मानक समय के रूप में किया जाता है।"

तो एक विशेष क्षेत्र के समय क्षेत्र को निर्धारित करने के लिए ऑफसेट के बजाय हमें क्या उपयोग करना चाहिए? इस क्षेत्र का नाम। अधिक सटीक रूप से, आपको एक ही समय क्षेत्र में उन क्षेत्रों में समूह बनाना चाहिए जिनमें वे समान रूप से गर्मियों और मानक समय पर स्विच करते हैं। आप पीटी (प्रशांत समय) जैसे नामों का उपयोग कर सकते हैं, लेकिन वे केवल वर्तमान मानक समय और गर्मियों के समय को जोड़ते हैं, और जरूरी नहीं कि सभी ऐतिहासिक परिवर्तनों को ध्यान में रखें। इसके अलावा, चूंकि पीटी केवल यूएसए और कनाडा में प्रचलन में है, इसलिए आपको अपने सॉफ़्टवेयर की सार्वभौमिकता सुनिश्चित करने के लिए प्रतिष्ठित संगठनों के स्थापित मानकों पर भरोसा करने की आवश्यकता है।

Iana समय क्षेत्र डेटाबेस

मुझे यह स्वीकार करना चाहिए कि समय क्षेत्र के बारे में जानकारी एक डेटाबेस है, नियमों का एक सेट नहीं है, क्योंकि इस जानकारी में सभी प्रासंगिक ऐतिहासिक परिवर्तन होने चाहिए। समय क्षेत्र से संबंधित कार्यों को हल करने के लिए कई मानक डेटाबेस तैयार किए गए हैं। सबसे अधिक बार, IANA टाइम ज़ोन डेटाबेस का उपयोग किया जाता है , और इसे आमतौर पर tz डेटाबेस (या tzdata) कहा जाता है। डेटाबेस में मानक समय में परिवर्तन और दुनिया भर में डीएसटी पर ऐतिहासिक डेटा शामिल हैं। इसके अलावा, इसे आयोजित किया जाता है ताकि सभी ऐतिहासिक डेटा की जांच संभव हो और सुनिश्चित करें कि समय यूनिक्स समय ( 1970.01/01 00:00:00 ) से शुरू हो रहा है। यद्यपि आप 1970 से पहले भी डेटाबेस में जानकारी पा सकते हैं, उनकी सटीकता की गारंटी नहीं है।

नामकरण सम्मेलन क्षेत्र / स्थान नियम का उपयोग करता है। महाद्वीप या महासागर (एशिया, अमेरिका, प्रशांत महासागर) का नाम आमतौर पर एक क्षेत्र के रूप में प्रयोग किया जाता है, और एक स्थान के रूप में मुख्य शहरों (सियोल, न्यूयॉर्क) के नाम। कारण यह है कि शहर आमतौर पर देशों की तुलना में लंबे समय तक रहते हैं। उदाहरण के लिए, दक्षिण कोरिया का समय क्षेत्र Asia/Seoul और जापान का Asia/Tokyo । यद्यपि दोनों देश समान UTC+09:00 ऑफसेट का उपयोग करते हैं, उनके स्थानीय समय अलग-अलग बदल गए, इसलिए उन्हें अलग-अलग समय क्षेत्रों में विभाजित किया गया।

आईएएनए आधार कई डेवलपर और इतिहासकार समुदायों द्वारा चलाया जाता है। ताजा पाया गया ऐतिहासिक डेटा तुरंत इसमें दर्ज किया जाता है और वर्तमान नीतियों को अपडेट किया जाता है, इसलिए आज डेटाबेस को सबसे विश्वसनीय स्रोत माना जा सकता है। इसके अलावा, यह कई यूनिक्स प्रणालियों द्वारा हुड के तहत उपयोग किया जाता है, जिसमें लिनक्स और मैकओएस शामिल हैं, साथ ही साथ जावा और पीएचपी सहित कई लोकप्रिय प्रोग्रामिंग भाषाएं भी हैं।

कृपया ध्यान दें कि Windows Microsoft डेटाबेस का उपयोग करता है । हालाँकि, यह ऐतिहासिक डेटा के संदर्भ में गलत है और केवल Microsoft द्वारा ही समर्थित है। इसलिए, आधार IANA आधार की तुलना में कम विश्वसनीय है।

जावास्क्रिप्ट और IANA

टाइमज़ोन संबंधित कार्यक्षमता को ब्लू से बाहर जावास्क्रिप्ट में लागू किया गया है। डिफ़ॉल्ट रूप से, भाषा वर्तमान क्षेत्र बेल्ट (अधिक सटीक रूप से, ओएस स्थापना के दौरान चयनित बेल्ट) का उपयोग करती है, और इसे बदलने का कोई तरीका नहीं है। इसके अलावा, यहां तक कि जावास्क्रिप्ट में डेटाबेस मानक के लिए विनिर्देश अस्पष्ट हैं, और आप खुद ही इसे समझ जाएंगे यदि आप 202015 के विनिर्देशन से निपटने का निर्णय लेते हैं। स्थानीय समय क्षेत्र और डीएसटी की उपलब्धता के बारे में, केवल अस्पष्ट बयान हैं। उदाहरण के लिए, डीएसटी को इस प्रकार परिभाषित किया गया है: ईसीएमएस्क्रिप्ट 2015 - डेलाइट सेविंग टाइम एडजस्टमेंट ।

यह एक कार्यान्वयन-आश्रित एल्गोरिथ्म है जो डेलाइटस्वाटिंग (टी) स्थानीय डेलाइट बचत समय सेटिंग को निर्धारित करने के लिए सर्वोत्तम उपलब्ध समय क्षेत्र जानकारी का उपयोग करता है, जिसकी गणना मिलीसेकंड में की जाती है। एक ECMAScript कार्यान्वयन को आपके स्थानीय डेलाइट बचत समय सेटिंग को बेहतर ढंग से निर्धारित करने में आपकी सहायता करनी चाहिए।

लगता है जैसे वे कहते हैं, "दोस्तों, इसे काम करने की कोशिश करो।" अन्य बातों के अलावा, आपको विभिन्न ब्राउज़रों के साथ संगतता समस्या को हल करना होगा। आप कहते हैं, "क्या गड़बड़ है!" और फिर निम्नलिखित पंक्ति पढ़ें:

नोट: हम अनुशंसा करते हैं कि आप अपने कार्यान्वयनों में IANA समय क्षेत्र डेटाबेस http://www.iana.org/time-zones/ से जानकारी का उपयोग करें।

हां। ECMA विनिर्देश आपको IANA डेटाबेस का उपयोग करने के लिए इस तरह की एक अनौपचारिक सिफारिश के साथ गेंद देते हैं, क्योंकि जावास्क्रिप्ट में एक विशेष मानक डेटाबेस नहीं है। नतीजतन, समय की गणना करने के लिए, विभिन्न ब्राउज़र समय क्षेत्र के साथ अपने स्वयं के संचालन का उपयोग करते हैं, जो अक्सर एक दूसरे के साथ असंगत होते हैं। बाद में, ECMA में, अंतर्राष्ट्रीय API के लिए, ECMA-402 Intl.DateTimeFormat प्रारूप में IANA डेटा का उपयोग करने का विकल्प Intl.DateTimeFormat । लेकिन यह विकल्प अन्य प्रोग्रामिंग भाषाओं में एनालॉग्स की तुलना में बहुत कम विश्वसनीय है।

सर्वर-क्लाइंट वातावरण में समय क्षेत्र

एक साधारण परिदृश्य पर विचार करें: हमें समय क्षेत्र निर्धारित करने की आवश्यकता है। मान लीजिए हम एक कैलेंडर बनाते हैं जो समय की जानकारी को संसाधित करेगा। जब क्लाइंट वातावरण में कोई उपयोगकर्ता पंजीकरण विंडो में एक दिनांक और समय दर्ज करता है, तो तारीख सर्वर में स्थानांतरित हो जाती है और डेटाबेस में संग्रहीत होती है। फिर क्लाइंट को सर्वर से स्क्रीन पर प्रदर्शन के लिए अनुसूची में पंजीकृत तारीख प्राप्त होती है।

यहां आपको कुछ तय करने की जरूरत है। क्या होगा यदि सर्वर तक पहुँचने वाले कुछ ग्राहक अलग-अलग समय क्षेत्रों में हैं? अनुसूची में घटना, जिसे 10 मार्च, 2017 को 23.30 बजे सियोल में पंजीकृत किया गया था, न्यूयॉर्क में 10 मार्च, 2017 को 9.30 बजे प्रदर्शित किया जाना चाहिए। सर्वर के लिए अलग-अलग समय क्षेत्रों से ग्राहकों की सेवा करने के लिए, उस पर संग्रहीत अनुसूची में पूर्ण मान होना चाहिए जो क्षेत्र पर निर्भर नहीं करता है। प्रत्येक सर्वर के पास ऐसे मूल्यों को संग्रहीत करने का अपना तरीका है, यह प्रश्न लेख के दायरे से परे है, क्योंकि सब कुछ एक विशिष्ट सर्वर या डेटाबेस पर निर्भर करता है। सामान्य तौर पर, क्लाइंट से सर्वर पर प्रेषित दिनांक और समय को एकल ऑफसेट (आमतौर पर UTC) के आधार पर या क्लाइंट वातावरण के समय क्षेत्र के बारे में जानकारी रखने वाले मूल्यों के रूप में प्रस्तुत किया जाना चाहिए।

आमतौर पर, ऐसे डेटा को यूटीसी प्रारूप में यूनिक्स समय के रूप में या ऑफसेट जानकारी के साथ आईएसओ -8601 मानक के अनुसार प्रेषित किया जाता है। यदि हमारे उदाहरण में हम 10 मार्च, 2017 को सियोल 21.30 को यूनिक्स समय में परिवर्तित करते हैं, तो हमें पूर्णांक मूल्य 1489113000 । और ISO-8601 प्रारूप में, स्ट्रिंग मान 2017–03–10T11:30:00+09:00 ।

यदि आप एक ब्राउज़र वातावरण में जावास्क्रिप्ट का उपयोग करते हैं, तो आपको ऊपर बताए अनुसार दर्ज किए गए मान को परिवर्तित करना होगा, और फिर उपयोगकर्ता के समय क्षेत्र से मिलान करने के लिए इसे वापस परिवर्तित करना होगा। इन दोनों समस्याओं को हल करना आवश्यक है। प्रोग्रामिंग भाषा के दृष्टिकोण से, पहले ऑपरेशन को "पार्सिंग" कहा जाता है, और दूसरा "स्वरूपण" है। अब देखते हैं कि यह जावास्क्रिप्ट में कैसे किया जाता है।

जब आप Node.js का उपयोग करके सर्वर वातावरण में JS के साथ काम करते हैं, तो आपको क्लाइंट से प्राप्त डेटा को पार्स करने की आवश्यकता हो सकती है। लेकिन चूंकि सर्वर और डेटाबेस के समय क्षेत्र आमतौर पर सिंक्रनाइज़ किए जाते हैं, और स्वरूपण क्लाइंट को सौंपा जाता है, एक ब्राउज़र वातावरण में आपको कई कारकों पर निर्णय लेने की आवश्यकता होती है। आगे मैं ब्राउज़र वातावरण के संबंध में समझाऊंगा।

जावास्क्रिप्ट तिथि वस्तु

किसी दिए गए समय या समय के साथ काम करने वाले कार्य Date ऑब्जेक्ट का उपयोग करके हल किए जाते हैं। यह एक देशी वस्तु है जिसे ECMAScript में परिभाषित किया गया है, जैसे Array या Function । यही है, यह अधिकांश भाग के लिए, C ++ जैसे मूल कोड का उपयोग करके लागू किया गया है। एपीआई को एमडीएन प्रलेखन में अच्छी तरह से वर्णित किया गया है। जावा से java.util.Date क्लास का ऑब्जेक्ट पर एक बड़ा प्रभाव था, इसलिए यह कुछ अवांछनीय गुणों को विरासत में मिला, जैसे कि म्यूटेबल डेटा की विशेषताओं और शून्य से शुरू होने वाला महीना।

हुड के तहत, एक जावास्क्रिप्ट Date ऑब्जेक्ट यूनिक्स-समय प्रारूप में पूर्ण मूल्यों का उपयोग करके समय के साथ काम करता है। लेकिन फ़ंक्शंस parse() और फ़ंक्शंस जैसे विधियाँ, getHour() , setHour() और अन्य क्लाइंट के टाइम ज़ोन से प्रभावित होते हैं (अधिक सटीक रूप से, ओएस में निर्दिष्ट बेल्ट जिसमें ब्राउज़र चल रहा है)। इसलिए यदि आप उपयोगकर्ता द्वारा दर्ज डेटा का उपयोग करके सीधे एक Date ऑब्जेक्ट बनाते हैं, तो ग्राहक का स्थानीय समय क्षेत्र इस डेटा में दिखाई देगा।

जैसा कि मैंने उल्लेख किया है, जावास्क्रिप्ट समय क्षेत्र को मनमाने ढंग से बदलने का कोई तरीका प्रदान नहीं करता है। इसलिए, हम मानते हैं कि हम सीधे ब्राउज़र में निर्दिष्ट समय क्षेत्र मान का उपयोग कर सकते हैं।

उपयोगकर्ता इनपुट का उपयोग करके एक दिनांक ऑब्जेक्ट बनाना

पहले उदाहरण पर लौटते हैं। मान लीजिए कि एक उपयोगकर्ता ने 11 मार्च, 2017 को 11.30 बजे अपने डिवाइस पर सियोल समय में प्रवेश किया। यह डेटा क्रमशः पांच संख्याओं: 2017, 2, 11, 11 और 30 - वर्ष, महीने, दिन, घंटे और मिनटों के रूप में सहेजा जाता है (माह 0 से शुरू होने पर, यह) मान 3–1 = 2) होना चाहिए। कंस्ट्रक्टर का उपयोग करके, आप आसानी से एक Date ऑब्जेक्ट बना सकते हैं:

 const d1 = new Date(2017, 2, 11, 11, 30); d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

यदि आप d1.toString() द्वारा d1.toString() गए मान को देखते हैं, तो आप देखेंगे कि 11 मार्च, 2017 को बनाई गई वस्तु का पूर्ण मूल्य 11:00 है, यह +09:00 (केएसटी) मिश्रण का उपयोग करके गणना की गई थी।

आप कंस्ट्रक्टर में स्ट्रिंग डेटा का उपयोग कर सकते हैं। यदि आप उन्हें Date लागू करते हैं, तो ऑब्जेक्ट आंतरिक रूप से Date.parse() कॉल Date.parse() सही मूल्य की Date.parse() । यह सुविधा RFC2888 और ISO-8601 विनिर्देशों का समर्थन करती है । लेकिन Date.parse () के लिए MDN प्रलेखन का कहना है कि इस विधि द्वारा लौटाया गया मूल्य ब्राउज़र पर निर्भर करता है, और स्ट्रिंग प्रकार का प्रारूप सटीक अंतिम मूल्य को प्रभावित कर सकता है। इसलिए, इस पद्धति का उपयोग न करना बेहतर है। उदाहरण के लिए, सफारी और इंटरनेट एक्सप्लोरर में, 2015–10–12 12:00:00 जैसे एक स्ट्रिंग मान NaN देता है, जबकि क्रोम और फ़ायरफ़ॉक्स में यह स्थानीय समय क्षेत्र लौटाता है। कुछ स्थितियों में, एक यूटीसी-आधारित मान लौटाया जाता है।

सर्वर डेटा का उपयोग कर एक दिनांक ऑब्जेक्ट बनाना

मान लीजिए आप एक सर्वर से डेटा प्राप्त करना चाहते हैं। यदि वे संख्यात्मक यूनिक्स समय के रूप में हैं, तो आप बस Date ऑब्जेक्ट बनाने के लिए कंस्ट्रक्टर का उपयोग कर सकते हैं। मैंने अभी तक यह उल्लेख नहीं किया है कि जब Date निर्माणकर्ता को एकल पैरामीटर के रूप में एक मान प्राप्त होता है, तो यह मिलीसेकंड में यूनिक्स समय मान की गणना करता है (ध्यान दें: जेएस मिलीसेकंड में यूनिक्स समय की प्रक्रिया करता है। इसका मतलब है कि दूसरा मूल्य 1000 से गुणा किया जाना चाहिए)। निम्नलिखित कोड निष्पादित करते समय, हमें पिछले उदाहरण के समान मूल्य मिलते हैं:

 const d1 = new Date(1489199400000); d1.toString(); // Sat Mar 11 2017 11:30:00 GMT+0900 (KST)

और अगर यूनिक्स-समय के बजाय स्ट्रिंग प्रकार ISO-8601 का उपयोग करें? जैसा कि मैंने ऊपर बताया, तो Date.parse() विधि अविश्वसनीय हो जाती है और इसका उपयोग न करना बेहतर है। हालाँकि, ECMAScript 5 से शुरू होकर, आप Internet Explorer 9.0 और इससे अधिक के Date निर्माण में ISO-8601 प्रारूप में स्ट्रिंग निर्माण का उपयोग कर सकते हैं।

यदि आप नवीनतम ब्राउज़र का उपयोग नहीं कर रहे हैं, तो सुनिश्चित करें कि Z मूल्यों के अंत में है। इसके बिना, आपका पुराना ब्राउज़र स्थानीय समय के आधार पर मूल्य की व्याख्या कर सकता है, यूटीसी नहीं। यहाँ Internet Explorer 10 में एक उदाहरण का उपयोग किया गया है:

 const d1 = new Date('2017-03-11T11:30:00'); const d2 = new Date('2017-03-11T11:30:00Z'); d1.toString(); // "Sat Mar 11 11:30:00 UTC+0900 2017" d2.toString(); // "Sat Mar 11 20:30:00 UTC+0900 2017"

विनिर्देश के अनुसार, दोनों मामलों में समान मूल्य प्राप्त किया जाना चाहिए। लेकिन वे अलग हैं। बाद के ब्राउज़र में, मान समान होंगे। इस समस्या को रोकने के लिए, यदि समय क्षेत्र की जानकारी उपलब्ध नहीं है, तो पंक्ति के अंत में हमेशा Z जोड़ें।

सर्वर को पास करने के लिए एक तारीख बनाना

अब आप पहले से बनाई गई Date उपयोग कर सकते हैं, स्थानीय समय क्षेत्रों के आधार पर स्वतंत्र रूप से पुनः प्राप्त या जोड़ सकते हैं। केवल प्रसंस्करण के अंत में सर्वर पर लौटने से पहले डेटा को पिछले प्रारूप में परिवर्तित करना न भूलें।

यदि यह यूनिक्स समय है, तो आप getTime() विधि का उपयोग कर सकते हैं getTime() मिलीसेकंड के बारे में मत भूलना)।

 const d1 = new Date(2017, 2, 11, 11, 30); d1.getTime(); // 1489199400000

ISO-8601 प्रारूप में स्ट्रिंग मान के बारे में क्या? जैसा कि मैंने कहा, इंटरनेट एक्सप्लोरर 9.0 और इसके बाद के संस्करण ECMAScript 5, और बाद के संस्करण ISO-8601 का समर्थन करते हैं। इसलिए, toISOString() या toJSON() विधियों का उपयोग करके, आप ISO-8601 में एक स्ट्रिंग बना सकते हैं ( toJSON() का उपयोग JSON.stringify() और अन्य) के साथ पुनरावर्ती कॉल के लिए किया जा सकता है। अमान्य डेटा संसाधित करते समय दोनों विधियाँ समान परिणाम देती हैं:

 const d1 = new Date(2017, 2, 11, 11, 30); d1.toISOString(); // "2017-03-11T02:30:00.000Z" d1.toJSON(); // "2017-03-11T02:30:00.000Z" const d2 = new Date('Hello'); d2.toISOString(); // Error: Invalid Date d2.toJSON(); // null

UTC स्ट्रिंग बनाने के लिए आप toGMTString() या toUTCString() विधियों का उपयोग कर सकते हैं। इसका परिणाम एक मूल्य होगा जो RFC-1123 का अनुपालन करता है।

Date ऑब्जेक्ट में toLocaleString() , toLocaleString() और उनके एक्सटेंशन विधियाँ शामिल हैं। लेकिन वे बहुत कम उपयोग के हैं, क्योंकि उनका उपयोग मुख्य रूप से स्थानीय समय क्षेत्र के आधार पर स्ट्रिंग्स को वापस करने के लिए किया जाता है, और लौटे मान ब्राउज़र और ओएस पर निर्भर करते हैं।

अपना स्थानीय समय क्षेत्र बदलें

जैसा कि आप देख सकते हैं, जेएस में कुछ प्रकार के समय क्षेत्र का समर्थन है। ? ? , JS . , . . , .

. . 11.30 11 2017 - . Unix- , - -05:00 . , .

getTimeZoneOffset() . API JavaScript, . :

 const seoul = new Date(1489199400000); seoul.getTimeZoneOffset(); // -540

-540 , 540 . , ( +09:00 ). , , . -, 60 * 5 = 300 . 840 Date . getXX . :

 function formatDate(date) { return date.getFullYear() + '/' + (date.getMonth() + 1) + '/' + date.getDate() + ' ' + date.getHours() + ':' + date.getMinutes(); } const seoul = new Date(1489199400000); const ny = new Date(1489199400000 - (840 * 60 * 1000)); formatDate(seoul); // 2017/3/11 11:30 formatDate(ny); // 2017/3/10 21:30

formatDate() -. , . , ? , . , — , . ( ).

, . , -, 11 15 . setDate() Date , , .

 ny.setDate(15); formatDate(ny); // 2017/3/15 21:30

, . , ? , getTime() getISOString() . , .

 const time = ny.getTime() + (840 * 60 * 1000); // 1489631400000

, , . Date ? नहीं। Date 11- 15-, 4 ( 24 * 4 * 60 * 60 * 1000 ). - 10- 15-, 5 ( 24* 5 * 60 * 60 * 1000 ). .

. , . - 12 , 15 2017 -04:00 , -05:00 . , 780 , 60 , .

 const time = ny.getTime() + (780 * 60 * 1000); // 1489627800000

, - , .

, . , , , . , , IANA .

, Date , . , . , . . JS . .

Moment Timezone

Moment — JavaScript-, . API , . Moment Timezone , . IANA API, .

. , . .

, Moment Timezone:

 const seoul = moment(1489199400000).tz('Asia/Seoul'); const ny = moment(1489199400000).tz('America/New_York'); seoul.format(); // 2017-03-11T11:30:00+09:00 ny.format(); // 2017-03-10T21:30:00-05:00 seoul.date(15).format(); // 2017-03-15T11:30:00+09:00 ny.date(15).format(); // 2017-03-15T21:30:00-04:00

seoul , ny -05:00 -04:00 . format() , ISO-8601, . .

निष्कर्ष

API , JavaScript, . , API, Internet Explorer 9 . , . , getTimezoneOffset() . , . Moment Timezone.

, , . : . , , , . , JavaScript . , .

जावास्क्रिप्ट में समय क्षेत्र के साथ काम करना