क्या .NET में समय क्षेत्र परिवर्तन का इतिहास है?

Question

हमारी सरकार स्थानीय समय बदलने या सक्षम करने के लिए प्यार करता है | डेलाइट सेविंग टाइम अक्षम करें।

रूस के लिए एमएस तैनात पैच खाते में नया समय बदलने के लिए तैनात किया गया।

अब सवाल है कि परिवर्तन का इतिहास मौजूद है या नहीं?

जब मुझे 01.01.2000 सिस्टम में दिन का यूटीसी समय मिलता है तो याद रखना चाहिए कि मास्को समय क्षेत्र में +3 यूटीसी था। (गर्मियों में +4) उस पल में।

01.01.2012 के लिए हमारे पास सर्दी और गर्मी दोनों के लिए +4 यूटीसी था। और जल्द ही हमारे पास +3 यूटीसी होगा।

साधारण परीक्षण से पता चलता है कि नेट परिवर्तन के बारे में रिकॉर्ड नहीं रखता है:

var t = new DateTime(2012,1,1); 
// UTC +4 expected 
System.Console.WriteLine(t.ToLocalTime()); 
// UTC +4 expected 
t = new DateTime(2012,06,1); 
System.Console.WriteLine(t.ToLocalTime()); 
// UTC +3 expected 
t = new DateTime(2000,1,1); 
System.Console.WriteLine(t.ToLocalTime()); 
// UTC +4 expected 
t = new DateTime(2000,6,1); 
System.Console.WriteLine(t.ToLocalTime()); 

कुछ अतिरिक्त एपीआई समस्या से निपटने के लिए मौजूद है?

अद्यतन:

मिल गया है वर्ग TimeZoneInfo और संबंधित AdjustmentRule वर्ग। यह जांचने के लिए बाएं कि TimeZoneInfo.Local समय क्षेत्र का अनुकूलन डेटटाइम एपीआई को प्रभावित करता है या नहीं।

अद्यतन 2: यूटीसी ऑफसेट की तरह लगता है वर्ष के दौरान केवल डेलाइट समय इतिहास और AdjustmentRule परिवर्तन के रूप में जमा नहीं कर रहे हैं।

Answer 1

नेट कुछ इतिहास ट्रैक करता है, लेकिन यह हमेशा सटीक नहीं होता है। आप एक गलतियों पर ठोकर खाई है।

.NET Windows से रजिस्ट्री के माध्यम से इसकी सभी समय क्षेत्र जानकारी आयात करता है, जैसा कि here और here वर्णित है। यदि आप HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Russian Standard Time\Dynamic DST पर रजिस्ट्री में देखते हैं तो आप पाएंगे कि यह केवल इस समय क्षेत्र के लिए 2010 से आगे की जानकारी ट्रैक करता है। वर्ष 2000 में परीक्षण तिथियां अच्छी तरह से काम नहीं कर रही हैं, क्योंकि यह जल्द से जल्द (2010) उपलब्ध हो जाएगी।

बेस यूटीसी ऑफसेट जानकारी रजिस्ट्री में ट्रैक, लेकिन AdjustmentRule वर्ग जो .NET इसे में आयात में नहीं है। आप इस समय क्षेत्र के लिए समायोजन नियमों की जांच, तो आप पाएंगे कि वर्ष 2012 से 2013 के बिलकुल नहीं आयात कर रहे हैं:

var tz = TimeZoneInfo.FindSystemTimeZoneById("Russian Standard Time"); 
foreach (var rule in tz.GetAdjustmentRules()) 
{ 
    Console.WriteLine("{0:d} - {1:d}", rule.DateStart, rule.DateEnd); 
} 

उत्पादन:

1/1/0001 - 12/31/2010 
1/1/2011 - 12/31/2011 
1/1/2014 - 12/31/2014 

हालांकि वे Windows रजिस्ट्री में मौजूद हैं, 2012 और 2013 आयात नहीं किए गए हैं क्योंकि उनके पास डेलाइट सेविंग टाइम एडजस्टमेंट नहीं है।

बेस ऑफ़सेट में परिवर्तन होने पर यह समस्या उत्पन्न होती है - जैसे कि इस समय क्षेत्र के लिए है। चूंकि यह वर्तमान में +3 है, और दो साल जहां यह +4 था आयात नहीं किया गया था, तो ऐसा लगता है कि उन लापता वर्षों के लिए +3 था।

TimeZoneInfo का उपयोग कर इसके लिए कोई अच्छा समाधान नहीं है। यहां तक ​​कि यदि आप अपना खुद का कस्टम समय क्षेत्र बनाने का प्रयास करते हैं, तो आपको उपलब्ध डेटा संरचनाओं में इस तरह के परिवर्तन को फ़िट करने में परेशानी होगी।

सौभाग्य से, एक और विकल्प है। आप Noda Time लाइब्रेरी के माध्यम से मानक IANA time zones का उपयोग कर सकते हैं।

निम्नलिखित कोड Noda समय का उपयोग करता है मिलान करने के लिए क्या आप अपने मूल कोड में लिखा है:

:

DateTimeZone tz = DateTimeZoneProviders.Tzdb.GetSystemDefault(); 
Console.WriteLine(Instant.FromUtc(2012, 1, 1, 0, 0).InZone(tz).LocalDateTime); 
Console.WriteLine(Instant.FromUtc(2012, 6, 1, 0, 0).InZone(tz).LocalDateTime); 
Console.WriteLine(Instant.FromUtc(2000, 1, 1, 0, 0).InZone(tz).LocalDateTime); 
Console.WriteLine(Instant.FromUtc(2000, 6, 1, 0, 0).InZone(tz).LocalDateTime); 

आपके स्थानीय समय क्षेत्र पहले से ही मास्को के लिए सेट नहीं है, तो आप करने के लिए पहली पंक्ति को बदल सकते हैं

DateTimeZone tz = DateTimeZoneProviders.Tzdb["Europe/Moscow"]; 

उत्पादन:

1/1/2012 4:00:00 AM 
6/1/2012 4:00:00 AM 
1/1/2000 3:00:00 AM 
6/1/2000 4:00:00 AM 

अद्यतन

AdjustmentRule के ऊपर वर्णित समस्या बेस ऑफसेट परिवर्तनों को ट्रैक न करने के लिए Microsoft समर्थन आलेख KB3012229 में वर्णित किया गया था, और बाद में .NET Framework 4.6 और .NET कोर में भी तय किया गया था।

the reference sources में, कोई देख सकता है कि AdjustmentRule अब m_baseUtcOffsetDelta फ़ील्ड रखता है। हालांकि इस क्षेत्र को सार्वजनिक संपत्ति के माध्यम से प्रकट नहीं किया गया है, यह गणनाओं में कारक है, और यदि आप FromSerializedString और ToSerializedString विधियों (यदि कोई वास्तव में उन का उपयोग करता है) का उपयोग करते हैं तो यह क्रमबद्धता में प्रतिबिंबित होता है।

Answer 2

आप NodaTime कोशिश कर सकते हैं,

http://nodatime.org/

बेहतर है क्या की व्याख्या करता है

http://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html

Answer 3

ऐतिहासिक समय क्षेत्र डेटा बहुत ही जटिल और छोटे अपवाद लागू के कई उदाहरण से भरा है विशिष्ट भौगोलिक क्षेत्रों में आज वर्णित होने का कोई आसान तरीका नहीं है। न केवल ऑफसेट बदल रहे हैं, बल्कि ऐसे क्षेत्र भी हैं जिन पर वे लागू होते हैं।

• http://www.iana.org/time-zones
• http://en.wikipedia.org/wiki/Tz_database

नेट का समर्थन नहीं करता है कि तुम क्या से बाहर हैं:

दुनिया यहाँ से इस डेटा के इतिहास मॉडल करने के लिए एक परियोजना है डिब्बा।समस्या के लिए एक सामान्य समाधान बनाना बहुत मुश्किल होगा, लेकिन अगर आप केवल उन्हीं क्षेत्रों का एक छोटा सेट पर की जरूरत है, तो आप इस पॉप्युलेट करने के लिए अपने आप को TimeZoneInfo class का उपयोग कर, जिसके लिए प्रलेखन राज्यों सक्षम होना चाहिए:

TimeZoneInfo वर्ग समर्थन के सदस्यों निम्न कार्रवाई:

• एक नए समय क्षेत्र पैदा कर रही है कि पहले से ही ऑपरेटिंग सिस्टम द्वारा परिभाषित नहीं