c # - Juster 'Sommertid' (DST) i .NET, ligesom Windows

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forsøger at replikere Windows Date &Time-indstillingerne i en UWP-applikation, og jeg har en dårlig tid med indstillinger for sommertid (DST).


Jeg har formået at få alt til at virke, jeg kan ændre systemets tid og tidssone lige fint fra min app, men indstillingen Juster automatisk til sommertid forvirrer mig.


Jeg troede først at det var nok at tjekke TimeZoneInfo.SupportsDaylightSavingTime, så fandt jeg ud af, at jeg sandsynligvis også skal kontrollere, om den aktuelt valgte dato/klokkeslæt er i DST-området ved at gøre TimeZoneInfo.IsDaylightSavingTime.


Nå, jeg troede jeg havde det rigtigt, men efter testen er min egen 'Adjust DST' -indstilling ikke den samme som Windows-indstillingen, og da jeg ikke kan se Windows-kildekoden, har jeg ingen idé om, hvilke andre forhold de er tjekker for at deaktivere/aktivere det.


Min UWP ansøgning:


Dato og klokkeslæt indstillinger i min UWP app [45]


Windows indstillinger:


Windows Dato og klokkeslæt indstillinger [46]


Mangler jeg stadig noget her? Mit andet spørgsmål vedrørende dette kan findes her for dem, der er interesserede.


Måske kan nogle MS devs med insiderinformation fortælle mig logikken bag denne skifteknap :-)


Tak på forhånd!


UPDATE:


Resultater fra tzutil viser, at når datoen er 16. maj 2011 og tidszone er Moskva (UTC + 3), slukker DST ved hjælp af kommandoen tzutil /s "Russian Standard Time\_dstoff" blot 'Russian Standard Time' uden \_dstoff, fordi DST ikke er relevant, og det stemmer overens med, hvad Windows rapporterer. [48]


Men hvorfor siger. NETs TimeZoneInfo klasse dette?
.NET siger, at dagens datetime er i DST-rækkevidde
Prøvede også med: [49]


var currentDateTime = new DateTime(2011, 5, 16, 0, 0, 0, DateTimeKind.Local);
var isDst = TimeZoneInfo.Local.IsDaylightSavingTime(currentDateTime); //True


Så. NET siger, at den aktuelle dato er i DST-rækkevidde, men DST kan ikke slukkes ved hjælp af TZUTIL eller fra Windows-indstillinger?


Måske mangler jeg noget meget indlysende her, men jeg ser det ikke ...


UPDATE:


Skiftende måned til februar, drejer Juster DST-skifte på i Windows, på grund af tilpasningsregler? Men i Helsinki har vi også disse overgange, og skiften er ikke handicappet? Hvad er anderledes?


UPDATE:


Besluttet ikke at gøre noget herom, og bare tjekke TimeZoneInfo.SupportsDaylightSavingTime. Det er ikke værd for alles tid eller energi at gøre det, ligesom Windows gør.

Bedste reference


Nogle ting at håndtere dine spørgsmål:



  • Brug aldrig klassen System.TimeZone. Det har mange problemer, og der er bedre alternativer. I de fleste .NET-koder skal du bruge System.TimeZoneInfo. Da du sagde, at du er skriver en UWP-applikation, kan du også få gavn af Windows.Globalization.Calendar og Windows.Globalization.DateTimeFormatting.DateTimeFormatter klasser. Åben kildebiblioteker som Noda Time kan også være et godt valg. [50] [51] [52] [53]


    I den første kodeblok du viste, bruger du System.TimeZone.IsDaylightSavingTime. Bemærkningerne i dokumenterne forklarer de resultater, du ser: [54]



      'Da TimeZone -kassen understøtter en enkelt regulering af sommertid, anvender IsDaylightSavingTime(DateTime) -metoden den aktuelle justeringsregel til en hvilken som helst dato, uanset om justeringsreglen trådte i kraft på den pågældende dato. selve operativsystemet har nøjagtige historiske dagslysbesparelsesdata, er der et mere præcist resultat ved hjælp af TimeZoneInfo.IsDaylightSavingTime metoden. Brug så vidt muligt TimeZoneInfo.IsDaylightSavingTime metoden. '


  • I den anden kodeblok du viste, bruger du System.TimeZoneInfo.IsDaylightSavingTime korrekt og får True, når du forventede False. Selv om dette er forvirrende og muligvis forkert, kan det forklares:



    • I 2011 startede Moskva kalenderåret på UTC + 3. Det ændrede derefter sin modregning til UTC + 4 den 27. marts kl 2:00 (referencer her). Dette var en ændring i standard tid , og ikke en DST-relateret ændring.

    • Datastrukturerne i Windows (TIME\_ZONE\_INFORMATION, DYNAMIC\_TIME\_ZONE\_INFORMATION og mere specifikt REG\_TZI\_FORMAT) understøtter ikke en ændring i standard offset i midten af ​​et kalenderår. De blev designet uden denne slags forandring i tankerne - for meget længe siden.

    • For at imødekomme ændringen i lokal tid er den modelleret i Windows som en DST-ændring, hvor DST-perioden starter den 27. marts klokken 2:00 og løber gennem enden af året. Dette holder den lokale tid præcis over overgangen på bekostning af at returnere unøjagtige oplysninger fra API'er, der angiver eller konkluderer, at deres resultater er eksplicit relateret til DST (såsom System.TimeZoneInfo.IsDaylightSavingTime.

    • Så tænk på sådanne metoder som at fortælle dig, om en periodes lokale tid er højere end UTC, end på et andet tidspunkt i året. Det kan være relateret til DST, eller det kan være relateret til en ændring i standard tid.


  • Så vidt jeg kan fortælle, ser Windows faktisk på disse data for at afgøre, om der skal vises mulighed eller ej. Hvis der er en overgang i det aktuelle kalenderår (som bestemt af systemuret), bliver indstillingen præsenteret - uanset om denne overgang var relateret til DST eller af en anden grund. [55]



Derudover nogle generelle råd:



  • De fleste applikationer skal ikke forsøge at ændre systemtid, tidszone eller DST-indstillinger. Selv om der virkelig er måder at gøre dette på, kan det få drastiske konsekvenser. Disse er system-wide globale indstillinger, som vil påvirke alt på computeren - ikke kun din ansøgning.


    Især at ændre tiden for drastisk kan påvirke evnen til at autentificere korrekt med andre systemer. For eksempel bruger Windows Authentication (Active Directory, SSPI, etc.) Kerberos - som har en 5-minutters tolerance fra UTC. Derudover kan adgang til websteder, der bruger sikkerhedscertifikater (HTTPS, SSL, TLS osv.) Mislykkes, hvis certifikatet er udløbet eller endnu ikke er udstedt, alt efter systemuret. Således er den sikreste vej til succes at sætte tid automatisk, og ikke tillade brugeren at afvige.


    Mens du ændrer tidszone og/eller DST-indstillinger ikke påvirker auth, er det stadig en global indstilling. Overalt på maskinen, der arbejder med lokal tid, vil afhente denne indstilling - ikke kun din ansøgning.

  • Hvis du rent faktisk vil ændre tidszonen, skal du huske, at du måske skal rydde den lokale tidszone cache for at hente den nye indstilling i din ansøgning. Se dette spørgsmål og svar for flere detaljer.

  • Hvis du kun har til hensigt at ændre tidszonen til din ansøgning, skal du bare holde øje med TimeZoneInfo.Id for den valgte tidszone og anvende den gennem TimeZoneInfo.ConvertTime og relaterede metoder, hvis det er nødvendigt.

  • Du skal sandsynligvis ikke have en indstilling til at deaktivere automatisk DST-justering. Eksistensen af ​​denne indstilling, der findes i Windows overhovedet, er en arv artefakt fra den oprindelige implementering af tidszoneindstillingerne fra de tidlige dage WinNT og Win9x. De fleste brugere skal forlade det.


    Slukning har kun én lovlig brugssag i disse dage, hvilket er når en regering annoncerer en ændring i tidszone fra en, der havde DST til en, der ikke har DST (eller har 'permanent DST') og er der ingen anden eksisterende tidszoneindtastning, der har samme baseforskydning uden DST og , når den nævnte regering ikke giver tilstrækkelig tid til Microsoft at oprette og distribuere en ny tidszoneindtastning for den berørte region, før ændringen træder i kraft. Sådanne ting sker, men er sjældne. IMHO, Det ville være rimeligt, at denne indstilling forsvinder på et eller andet tidspunkt i fremtiden. personlig mening, ikke taler for Microsoft på dette.)


Andre referencer 1


Ok, jeg regnede med det ved at se på strukturen for de tilgængelige dato/klokkeslæt indstillinger i kontrolpanelet. Grunden til, at dit skifte i kontrolpanelvisningen er deaktiveret, er på grund af dette:


Indtast billedbeskrivelse her [57]


Den placering, du har valgt i kontrolpanelet, overholder ikke dagslysbesparelser. Jeg prøvede det på min computer, og det gjorde det samme:


Indtast billedbeskrivelse her [58]


Så med dette er jeg i USA, og vi observerer dagslysbesparelser:


Indtast billedbeskrivelse her [59]


og nu kontrolpanelet


Indtast billedbeskrivelse her [60]


så hvad det forklarer er, at Microsoft laver lister for at afgøre, om en placering overholder dagslysbesparelser. For at få din drejekontakt til at arbejde skal du bruge if else statements, så det er hvad du skal gøre:


Lav to lister med Observable og NonObservable sommertid. Derefter skal du binde din omskifter til enabled og disabled til listerne. Når du vælger TimeZone i din app, skal du i sommerdagsdelen finde de angivne dage, de ændrer. På disse dage binder Fall Back og Spring Forward op på de dage, de bevæger sig fremad eller falder tilbage på den angivne tid.


USA har 7 tidszoner. EST, CST, MST, PST, AKDT, HADT og HST. Så for hver tidszone skal du gøre noget som dette:


if (TimeZone == ObservableList)
   {
         toggleSwitch.Enabled = true;   
   }
else     
   {
         toggleSwitch.Enabled = false
   }


Hvad dette gør er, indstiller parameteren, når omskifteren er enabled mod disabled og så skal du tilslutte hour change for hver tidszone. Så du skal hardt kode begivenhederne, eller du kunne bruge den betalte service af World Time API


Jeg håber det hjælper og giver dig en ide. Du kan teste hvad jeg gjorde, bare gå til dato/klokkeslætskift i kontrolpanelet og ændre tidszoner, du vil se, at skiftet skifter til enabled til disabled og omvendt i henhold til Beliggenhed. Jeg har ikke testet koden, men det giver dig en ide, og for mig virker det som en meget lang proces. Microsoft har pengene, så de sandsynligvis piggyback off World Time API vs hard coding.

Andre referencer 2


Dette er en teori til svaret, og min teori er logisk bakket op, men ser på den oplagte https://en.m.wikipedia.org/wiki/Daylight\_saving\_time\_by\_country nogle lande observerer sommertid og nogle gør det ikke. [61]


Så i teorien kan MS-koden for denne struktur være på en If else erklæring for at inkludere hvilke lande der observeres i forhold til dem, der ikke er.


Hvis du tænker på at bruge geolocate på en bærbar computer, er i en observeret erklæring, og den bærbare computer er flyttet til et land, der ikke følger, så spørgsmålet ville være, at denne placering observerer sommertid.


Du har Rusland som eksempelbyen, hvis dette er sandt, så ville Rusland være på en ikke observere erklæring. Rusland afslutter overholdelsen af ​​DST i 2014.


MS er virkelig kræsen om at frigive kode. Men jeg har en ven, der plejede at arbejde med MS til ham og 1.800 mennesker blev afskediget, han forklarede dette for mig før om andre MS-funktioner.


Så dette kan svare på spørgsmålet, eller det kan vise, at MS har lagt meget tid på OS'en på geolocate. Nu er det store spørgsmål, om geolocate er slukket, vil den bærbare computer stadig ændre dato og klokkeslæt, hvis det krydser tidszoner og andre scenarier.


Personligt ved jeg ikke svaret, men det er min teori. Jeg har tidligere haft et problem og måtte bruge Hvis ellers bestemme, hvilken løsning der er den rigtige løsning.


Jeg håber det hjælper, i det mindste vil det give dig et godt eksempel.


*********** Addition **********


Her bruges et eksempel, men det giver dig en ide om, at du kan strukturere det. https://msdn.microsoft.com/en-us/library/ms973825.aspx#datetime\_topic6 Dette forklarer to scenarier, og en af ​​dem sætter datoer og tider i string format. Den anden kaldes en 25 timers dag. [62]