2008-11-05 24 views
43

Một vài tháng trước, tôi đã được giới thiệu với loại DateTimeOffset mới và rất vui mừng vì lỗi của DateTime liên quan đến múi giờ cuối cùng đã được xử lý.Khi nào bạn sẽ thích DateTime hơn DateTimeOffset

Tuy nhiên, tôi đã tự hỏi liệu có bất kỳ nguyên nhân hoặc vấn đề nào có thể xảy ra khi sử dụng loại mới này hay không.

Tôi làm việc trên ứng dụng web đa ngôn ngữ. Có ai biết bất cứ điều gì có thể ảnh hưởng tôi từ chỉ sử dụng nó cho tất cả các công việc ngày/giờ của tôi? Ở đây có cửa sổ lạm dụng không?

tham khảo: DateTimeOffset: A New DateTime Structure in .NET 3.5 by Justin Van Patten

+0

Câu hỏi liên quan - http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices – Oded

+0

Xem thêm [câu trả lời này] (http://stackoverflow.com/a/14268167) –

Trả lời

42

Đôi khi bạn thực sự chỉ muốn đại diện cho một (múi giờ không biết) ngày "địa phương" và thời gian chứ không phải là một tức trong thời gian. Thành thật mà nói, thường chỉ hữu ích khi đại diện cho một thời gian - ví dụ: "đánh thức tôi dậy lúc 8 giờ sáng, bất kể múi giờ" - nhưng ngày tháng và thời gian cũng có thể hữu ích.

Tôi đồng ý rằng đối với phần lớn các trường hợp, DateTimeOffset phù hợp hơn. Nó tấn công tôi như là lẻ mà không có một cấu trúc DateTimeTimeZone có cả múi giờ và múi giờ của nó mặc dù ... một bù đắp không thực sự cung cấp cho bạn tất cả thông tin bạn cần. (Ví dụ, cho một DateTimeOffset, bạn không biết thời gian sẽ là 24 giờ sau đó, bởi vì bạn không biết khi nào DST có thể đá vào.)

Nếu bạn muốn loại cấu trúc đó, tôi có một very crude implementation in another answer. Tôi chắc chắn rằng nó có thể được cải thiện rất dễ dàng :)

+2

Bạn luôn có thể thể hiện thời gian của bạn trong UTC và chuyển đổi thành múi giờ cụ thể khi cần ... –

+2

Omer: Nhưng thông thường bạn cũng muốn giữ thông tin múi giờ. Có, thông thường bạn có thể lấy đi chỉ với thời gian UTC, nhưng đối với các sự kiện thường xuyên và tương tự, bạn cũng cần phải biết múi giờ. –

+0

Giờ địa phương thường chỉ nên được sử dụng cho các ngày trong tương lai, nơi bạn muốn chúng điều chỉnh theo các thay đổi múi giờ. Dữ liệu lịch sử phải luôn được lưu trữ trong một múi giờ nhất quán, có thể là UTC mặc dù có thể có lý do lịch sử khác. (Ví dụ: đối với dữ liệu giao dịch NYSE, bạn có thể muốn EST trên bảng). – Ben

3

Vâng, một câu trả lời rõ ràng là khi bạn cần hỗ trợ khách hàng không có SP mà nó gửi vào (nó không thực sự ở 3,5 - đó là trong 2.0 SP1 , được vận chuyển cùng một lúc).

+0

Đúng, nhưng tôi đã thực sự nói về nội bộ trong mã của tôi và trong lớp giao diện người dùng. –

+2

Đủ công bằng. Tôi nghĩ rằng tôi muốn đề cập đến nó vì VS đa targetting không làm cho nó rõ ràng khi bạn đã sử dụng các tính năng SP1 trong khi bị cáo buộc nhắm mục tiêu 2.0. Hiện tại có một bổ trợ FxCop (v.v.) để làm điều này, ít nhất. –

Các vấn đề liên quan