Jak radzić sobie, gdy strefa czasowa cofa się w przyszłości

Question

Generuję dwa zestawy powtarzających się zdarzeń w oddzielnych iteracjach pętli, ale mam konflikt podczas porównywania wygenerowanych wyników dla konfliktów. Wydaje się, że czasy się cofają i nie jestem pewien, jak rozwiązać ten problem?

pierwszego powtórzenia Impreza:

• powtarzać codziennie o godzinie 00:00 do 01:00 w "Europe/Stockholm" Czas
• z 03/11/2015
• pętli aż na wieki.

Drugim wydarzeniem będzie powtarzać:

• powtarzać codziennie o 01:00 do 02:00 w "Europe/Stockholm" czas
• z 03/11/2015
• ponownie pętli na zawsze .

Aby wygenerować zdarzeń mam przelotowego codziennie w lokalnej strefy czasowej „Europa/Stockholm” używając Nodatime tak:

String timeZone = "Europe/Stockholm"; 
for (ZonedDateTime date_Local = repeatSeriesStartDate_Local; date_Local <= LoopEndDate_Local; date_Local = new ZonedDateTime(Instant.FromDateTimeUtc(date_Local.ToDateTimeUtc().AddDays(1).ToUniversalTime()),timeZone)) 

Mój problem powstaje w dniu 29 października/30-cia 2016 Kiedy zegary przejść wstecz i druga reguła jest w konflikcie z pierwszą. http://www.timeanddate.com/time/change/sweden/stockholm?year=2016

czasów konfliktu są następujące:

• "2016-10-29T23: 00: 00Z" na "2016-10-30T01: 00: 00Z"
• „2016-10- 30T00: 00: 00Z”na "2016-10-30T01: 00: 00Z"

Używam algorytm podobny do tego, aby przetestować konfliktów https://stackoverflow.com/a/325964/884132

Jak radzić sobie z tymi konfliktami czasowymi?

Answer 1

Choć byłoby bardzo pomocne, jeśli wyjaśnisz pytanie, zrobię kilka założeń na teraz. W razie potrzeby mogę edytować pytanie później.

Co prawdopodobnie chcesz zrobić jest mniej więcej tak:

for (LocalDate date = startDate; date <= endDate; date = date.PlusDays(1)) 
{ 
    ZonedDateTime zdt = date.At(eventTime).InZone(tz, SchedulingResolver); 
    Console.WriteLine(zdt); // or whatever you want to do from here 
} 

Realizacja SchedulingResolver jest here i jest konieczne tylko w przypadku korzystania z wersji 1.x od Noda Czasu. Jeśli używasz wersji 2.x, możesz zamiast tego użyć po prostu InZoneLeniently(tz), ponieważ zachowanie łagodnego przelicznika w wersji 2.x zmieniło się tak, aby pasowało (zobacz "łagodne zmiany w tłumaczeniu" w the 2.x migration guide).

Kluczowe punkty to:

• ZonedDateTime jest często używane jako typ pośredniczącej.

  • Masz codzienne wydarzenia, które są oparte na lokalnym dniu, więc bardziej odpowiednie jest ustawienie LocalDate.

  • Jeśli miałeś zdarzenia oparte na ustalonym 24-godzinnym obrocie (inaczej na Dniu UTC), bardziej odpowiednie byłoby ustawienie Instant.

• przeliczniki są używane do mapowania niejednoznaczne lub nieprawidłowe LocalDateTime wartości z powrotem do konkretnych momentów w czasie. Resolver Polecam dla celów planowania jest ten, który:

  • Postępy przez ukos DST (zwykle 1 godzinę), kiedy zegary naprzód (wiosna)
  • Picks pierwszej instancji, gdy zegary wrócić (spadek)

Choć jak wspomniano Jon - twoje potrzeby mogą się różnić, a tak naprawdę nie możemy odpowiedzieć na to, co powinny zrobić. Są rzeczywiście firmy, które wymagają różnych reguł rozstrzygania niż te, które polecam.