Toán tử chênh lệch ngày tháng xem xét tiết kiệm ánh sáng ban ngày?

Question

Theo như tôi biết các nhà điều hành khác biệt của các loại DateTime xem xét năm nhuận: để

new DateTime(2008, 3, 1) - new DateTime(2008, 2, 1) // should return 29 days 
new DateTime(2009, 3, 1) - new DateTime(2009, 2, 1) // should return 28 days 

Nhưng những gì về tiết kiệm ánh sáng ban ngày?

Answer 1

Tôi không nghĩ điều đó sẽ xảy ra. The documentation chỉ đơn giản nói rằng một DateTime được lưu trữ như số lượng bọ ve từ 12:00:00 nửa đêm, ngày 1 tháng 1, 0001, nhưng nó không nói trong đó TimeZone nửa đêm thực sự là - tôi sẽ phải giả định rằng nếu nó luôn luôn được lưu trữ nội bộ trong UTC, họ sẽ nói như vậy.

Bạn có thể dễ dàng nhận được xung quanh mặc dù điều này: Chỉ cần làm:

var difference = Dt1.ToUniversalTime() - Dt2. ToUniversalTime() 

và chuyển đổi để UTC sẽ đưa vào tiết kiệm ánh sáng ban ngày tài khoản

Answer 2

Kiểm tra và xem!

Dễ dàng viết bài kiểm tra như bạn đã làm cho trường hợp DST như trong trường hợp năm nhuận.

Answer 3

Thời gian tiết kiệm ánh sáng ban ngày cụ thể hơn 12 múi giờ chung và quốc gia nào sử dụng chúng.

Các quốc gia hoặc nhóm quốc gia khác nhau sử dụng các ngày khác nhau khi DST xảy ra.

một chút đau đớn của nó thực sự chưa kể đến các quốc gia không làm điều đó, hoặc một phần của các quốc gia.

Ví dụ: Queensland, AU doenst có DST kiểm tra phần còn lại của quốc gia.

Tôi sẽ không ngạc nhiên nếu điều đó không xảy ra, trong trường hợp nó không thể thực hiện điều đó với ít nhất một cultureinfo ít nhất là 9at).

Answer 4

Nó sẽ không và nó trong thực tế KHÔNG THỂ, dựa trên thực tế là nó không hoặc là lực lượng bạn sử dụng UTC để xây dựng một DateTime cũng không cho phép bạn chỉ định cho dù DST có hiệu lực khi bạn xây dựng một DateTime với một giá trị thời gian địa phương. Hơn nữa, nó cho phép các chế độ (LT hoặc UTC) được "không xác định", mà chỉ là asinine.

Bằng cách cho phép xây dựng giá trị DateTime từ giá trị Giờ địa phương, có thể tạo giá trị DateTime (được chỉ định là Giờ địa phương) không rõ ràng (ví dụ: bất kỳ thời gian nào từ 1 đến 2 giờ sáng ngày 2 tháng 11 ở Hoa Kỳ, khi giờ địa phương lặp lại chính nó) và không thể được chuyển đổi xác định trở về UTC, KHÔNG GIỚI HẠN hàm tạo cung cấp một tham số để xác định xem DST có ảnh hưởng đến thời gian cục bộ đã cho hay không.

Vì không cung cấp thông số như vậy, thiết kế lớp DateTime không đầy đủ và thiếu sót, không xem xét tất cả các thông số cần thiết để chỉ định đúng thời gian cục bộ.

Tôi nghĩ đó là lý do tại sao họ tạo lớp DateTimeOffset, mà ... nếu bạn nhầm lẫn lý do tại sao một lớp dường như dư thừa như vậy tồn tại ... đó là lý do.

Kết quả là, bạn sẽ không bao giờ thực hiện bất kỳ loại phép tính nào với bất kỳ cá thể DateTime nào không được đặt thành DateTimeMode.Utc. Chỉ sử dụng UTC. Bạn thực sự không thể chuyển đổi sang hoặc từ LT, bởi vì nó BUSTED bởi hai lỗi khác nhau, cả hai cách. 1.Đi từ LT đến UTC bị vỡ vì, như đã đề cập, nó không cho phép bạn chỉ định liệu DST có hiệu lực trong một giờ không rõ ràng trong LT. Ồ, nó cũng cho phép bạn chỉ định giờ địa phương về cơ bản là không thể, chẳng hạn như giờ chúng tôi bỏ qua khi đồng hồ được đặt trước. 2. Khi chuyển đổi giá trị UTC trong quá khứ thành giờ địa phương, các ốc vít Windows có nghĩa là bù đắp cho DST dựa trên việc nó có hiệu lực vào NGAY BÂY GIỜ, đúng hơn là thời gian đã cho, mà là nghiêm trọng asinine. Tất nhiên, bạn có thể đã nhận thấy vấn đề này khi một thời gian sửa đổi bạn đã viết, lưu trữ, hoặc được sử dụng trong tên của một tập tin, một ngày cho thấy một HOUR OFF trong Windows explorer. Không, bạn không điên, Windows chỉ có một lỗi nghiêm trọng trong đó, mà họ không bao giờ tìm thấy thời gian để sửa chữa một nơi nào đó giữa việc phát hành của DOS và khuôn khổ .NET mới nhất (~ 2 thập kỷ)! Tất nhiên, lỗi đó ảnh hưởng đến hệ thống CVS và bất kỳ thứ gì theo dõi thời gian sửa đổi. Hệ thống tập tin FAT lưu trữ thời gian như thời gian địa phương, có nghĩa là nó chỉ hoàn toàn hơi say.

Answer 5

.NET không xử lý chính xác thời gian tiết kiệm ánh sáng ban ngày, mặc dù nó cung cấp câu trả lời bạn muốn. Bạn muốn câu trả lời không chính xác.

phiên bản ngắn:

• Làm thế nào NET có thể biết rằng vào năm 1977 giờ mùa hè đã có hiệu lực trong cả năm, do cuộc khủng hoảng năng lượng?

• Làm cách nào để biết quy tắc tiết kiệm ban ngày sẽ là gì ở Israel, khi quy tắc được quyết định hàng năm bởi Knesset? Làm thế nào để biết rằng Hoa Kỳ chạy trên DST quanh năm trong Thế chiến II, và từ năm 1945 đến năm 1966 các quy tắc DST thay đổi khu vực đến khu vực, và các quy tắc vẫn làm thay đổi khu vực đến khu vực.

.NET cố gắng cảnh báo và sử dụng quy tắc tiết kiệm ánh sáng ban ngày, ngay cả khi chúng không có hiệu lực hoặc sẽ có hiệu lực. Kết quả là bạn nhận được câu trả lời, trong khi đó là những gì bạn nghĩ rằng bạn muốn, là không chính xác.

Từ blog entry Raymond Chen 's, Why Daylight Savings Time is nonintuitive:

Tại sao không phải là (win32) thời gian chuyển đổi chức năng khu vực sử dụng thích hợp múi giờ cho thời điểm trong năm?

...

Win32 không cố gắng đoán mà quy tắc múi giờ đã có hiệu lực vào đó thời gian khác. Vì vậy, Win32 nói, "Thứ năm, ngày 17 tháng 10 năm 2002 8:45:38 AM PST".

Lưu ý: Thái Bình Dương Chuẩn Thời gian. Thậm chí dù 17 Tháng 10 là trong Thái Bình Dương Daylight Time, Win32 hiển thị thời gian như thời gian tiêu chuẩn bởi vì đó là những gì thời gian đó là tại.

.NET nói, "Vâng, nếu các quy tắc trong hiệu lực hiện cũng có hiệu lực vào ngày 17 tháng 10 năm 2003, thì đó sẽ là giờ ban ngày" để hiển thị "Thứ năm, ngày 17 tháng 10 năm 2003, 9:45 SA PDT "- thời gian ban ngày.

Vì vậy, câu trả lời bạn nhận được là sai. Nhưng kể từ khi bạn mong đợi câu trả lời sai, đó là những gì bạn nhận được.