Làm thế nào để xử lý khi múi giờ đi ngược trong tương lai

Question

Tôi đang tạo hai tập hợp sự kiện lặp lại trong các vòng lặp riêng biệt nhưng có xung đột khi so sánh kết quả được tạo cho các xung đột. Điều này có vẻ là khi thời gian quay trở lại và tôi không chắc chắn làm thế nào để giải quyết điều này?

Sự kiện lặp lại đầu tiên sẽ:

• lặp lại hàng ngày tại 0:00-01:00 trong "Châu Âu/Stockholm" Lần
• từ 2015/03/11
• vòng lặp cho đến mãi mãi.

Sự kiện lặp lại thứ hai sẽ:

• lặp lại hàng ngày tại 1:00-02:00 trong "Châu Âu/Stockholm" Lần
• từ 2015/03/11
• một lần nữa lặp mãi mãi .

Để tạo ra các sự kiện mà tôi đang Looping qua hàng ngày trong khu vực địa phương thời gian "Châu Âu/Stockholm" sử dụng Nodatime như thế này:

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)) 

Vấn đề của tôi xuất hiện vào ngày 29/30 2016 Khi đồng hồ đi ngược lại và quy tắc thứ hai xung đột với quy tắc đầu tiên. http://www.timeanddate.com/time/change/sweden/stockholm?year=2016

Giờ mâu thuẫn như sau:

• "2016-10-29T23: 00: 00Z" thành "2016-10-30T01: 00: 00Z"
• "2016-10- 30T00: 00: 00Z" thành "2016-10-30T01: 00: 00Z"

tôi đang sử dụng một thuật toán như thế này để kiểm tra xung đột https://stackoverflow.com/a/325964/884132

Tôi nên xử lý các xung đột chuyển dịch thời gian này như thế nào?

Answer 1

Mặc dù nó thực sự hữu ích nếu bạn sẽ làm rõ câu hỏi, tôi sẽ đưa ra một vài giả định cho bây giờ. Tôi có thể chỉnh sửa câu hỏi sau nếu cần.

gì có thể bạn muốn làm là một cái gì đó như thế này:

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 
} 

Việc thực hiện SchedulingResolver là here, và chỉ cần thiết nếu bạn đang sử dụng phiên bản 1.x của Noda Time. Nếu bạn đang sử dụng 2.x, thì bạn chỉ có thể sử dụng InZoneLeniently(tz) thay vì hành vi của trình giải quyết khoan dung trong 2.x đã thay đổi để khớp (xem "thay đổi giải pháp khoan dung" trong the 2.x migration guide).

Những điểm chính là:

• ZonedDateTime thường nhất được sử dụng như một loại trung gian.

  • Bạn có các sự kiện hàng ngày dựa trên ngày địa phương, vì vậy LocalDate phù hợp hơn.

  • Nếu bạn có sự kiện dựa trên vòng xoay 24 giờ cố định (còn gọi là ngày UTC), thì Instant sẽ phù hợp hơn.

• phân giải được sử dụng để lập bản đồ không rõ ràng hoặc không hợp lệ LocalDateTime giá trị trở lại những khoảnh khắc đặc biệt trong thời gian. Resolver Tôi khuyên bạn nên cho các mục đích lập kế hoạch là một trong đó:

  • Ưu đãi của các thiên vị DST (thường là 1 giờ) khi đồng hồ đi về phía trước (mùa xuân)
  • Picks trường hợp đầu tiên khi đồng hồ trở lại (mùa thu)

Mặc dù như Jon nói - nhu cầu của bạn có thể thay đổi, và thực sự chúng tôi không thể trả lời những gì bạn nên làm. Có thực sự kinh doanh cần các quy tắc giải quyết khác với những quy tắc tôi đang đề xuất.