टेल ऑफ़ लॉस्ट मॉस्को टाइम, या व्हाट्स माइक्रोसॉफ्ट गाईज़ मिस्टेक

दूसरे दिन, मुझे पछतावा हुआ कि विंडोज ऑपरेटिंग सिस्टम परिवार में मास्को समय के बारे में गलत जानकारी है। यह उल्लेखनीय है कि त्रुटि अभी तक ठीक नहीं हुई है, हालांकि यह 2011 में सिस्टम में वापस लीक हो गया। .NET के उपयोग से त्रुटि के परिणाम दिखाए जाएंगे, लेकिन यह उन सभी तकनीकों के लिए सही है जो समय क्षेत्र और समय के आधार पर विंडोज डेटा पर भरोसा करते हैं।

इसलिए, मेरी कार में मॉस्को का समय क्षेत्र निर्धारित है:


हम UTC में दिनांक 09.03.2014 10:00 बनाते हैं। फिर हम इसे मॉस्को समय में अनुवाद करते हैं। जैसा कि आप जानते हैं, अब मास्को के लिए UTC + 04: 00 ऑफसेट पूरे वर्ष चल रहा है:

var dt = new DateTime(2014, 3, 9, 10, 0, 0, DateTimeKind.Utc); //09.03.2014 10:00 UTC Console.WriteLine("UTC: {0},\nMoscow: {1}",dt, dt.ToLocalTime() ); 

हमें मिलता है:

UTC: 03/09/2014 10:00:00,
मॉस्को: 03/09/2014 14:00:00

खैर, बुरा नहीं है। हालाँकि, हम अतीत में थोड़ी गहराई से उतरेंगे। सर्दियों के समय के लिए घड़ी को रद्द करने से पहले, हमारे देश ने वर्ष में दो बार घड़ी के हाथों का अनुवाद किया। सर्दियों में, मॉस्को समय में UTC + 03: 00 और गर्मियों में UTC + 04: 00 की पारी थी।
हम UTC में दिनांक 09.03.2010 10:00 के लिए ऑपरेशन दोहराते हैं।

 var dt = new DateTime(2010, 3, 9, 10, 0, 0, DateTimeKind.Utc); //09.03.2010 10:00 UTC Console.WriteLine("UTC: {0},\nMoscow: {1}",dt, dt.ToLocalTime() ); 

हमें मिलता है:

UTC: 03/09/2010 10:00:00,
मॉस्को: 03/09/2010 14:00:00

कुछ गड़बड़ है। मार्च 2010 में, सर्दियों का समय प्रभाव में था, जिसके लिए ऑफसेट +03: 00 घंटे, और +04: 00 नहीं होना चाहिए। इसी तरह, गर्मियों के समय के लिए (जून 2010):

 var dt = new DateTime(2010, 6, 9, 10, 0, 0, DateTimeKind.Utc); //09.06.2010 10:00 UTC Console.WriteLine("UTC: {0},\nMoscow: {1}",dt, dt.ToLocalTime() ); 

UTC: 06/09/2010 10:00:00,
मॉस्को: 06/09/2010 15:00:00

गर्मियों में, ऑफसेट +04: 00 था, लेकिन हमें ऑफसेट +05: 00 मिला, जो मॉस्को समय क्षेत्र में कभी नहीं था!

मामला क्या है?

समय क्षेत्र की जानकारी को विंडोज रजिस्ट्री में संग्रहीत किया जाता है और पैच के साथ अद्यतन किया जाता है। Tz डेटाबेस का उपयोग करने के बजाय, जो वैश्विक समय क्षेत्र की जानकारी को अद्यतन करता है (और जिसका उपयोग * nix सिस्टम, BSD सिस्टम और मैक OS X में किया जाता है), Microsoft अपना स्वयं का डेटाबेस रखता है।

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

• आधार ऑफसेट: UTC + 03: 00
• सर्दी का समय = आधार ऑफसेट
• ग्रीष्मकालीन समय = आधार ऑफसेट +01: 00

सर्दियों के समय पर स्विच को रद्द करने के बाद, हॉटफिक्स सामने आया, जो मॉस्को के लिए वर्ष-दर-वर्ष की पारी UTC + 04: 00 को ठीक करने वाला था। लेकिन एक त्रुटि हुई। स्थायी डेलाइट सेविंग टाइम सेट करने के बजाय, Microsoft ने आधार ऑफ़सेट को +03: 00 से +04: 00 तक बदल दिया और स्थायी सर्दियों के समय को चालू कर दिया। लेकिन तथ्य यह है कि Microsoft समय क्षेत्र डेटाबेस में आधार ऑफ़सेट में बदलाव के बारे में ऐतिहासिक जानकारी नहीं है। नतीजतन, 2010 की गर्मियों से पहले की तारीखों के लिए, निम्नलिखित स्थिति प्राप्त की जाती है। जब सर्दियों का समय प्रभाव में होता है, तो इसकी पारी आधार के साथ मेल खाती है। पैच जारी होने से पहले, यह +03: 00 था, और अब यह +04: 00 हो गया है। जब डेलाइट सेविंग टाइम प्रभावी होता है, तो इसमें आधार के सापेक्ष +01: 00 का ऑफसेट होता है। पहले, यह +04: 00 निकला, और पैच जारी होने के बाद यह +05: 00 हो गया।

कुछ समय बाद, यह समस्या देखी गई , और Microsoft ने एक और हॉटफ़िक्स तैयार किया, जो वर्तमान स्थिति को ठीक करने वाला था। हालाँकि, इसे स्थापित करने से समस्या ठीक नहीं होती है।

फिलहाल, यह प्रयोगात्मक रूप से पाया गया है कि त्रुटि विंडोज 7, विंडोज 8, साथ ही विंडोज सर्वर 2008 आर 2 पर पुन: प्रस्तुत की जाती है। .NET के मामले में, इस समस्या को NodaTime पुस्तकालय का उपयोग करके तिथियों के साथ काम करके हल किया जा सकता है, जो tz डेटाबेस का उपयोग करता है।