Một kiểu chỉ dành cho Ngày trong C # - tại sao không có kiểu Ngày?

Trong dự án C # của chúng tôi, chúng tôi có nhu cầu đại diện cho một ngày không có thời gian. Tuy nhiên, tôi biết về sự tồn tại của DateTime, nó cũng kết hợp cả thời gian trong ngày.Tôi muốn nói rõ rằng một số biến và đối số phương thức nhất định dựa trên ngày tháng . Do đó tôi không thể sử dụng DateTime.Datetài sản

Các cách tiếp cận tiêu chuẩn cho vấn đề này là gì? Chắc chắn tôi không phải là người đầu tiên gặp phải điều này? Tại sao không cóDate lớp trong C #?

Có ai có cách triển khai hay bằng cách sử dụng cấu trúc và có thể là một số tiện ích mở rộng trên DateTime và có thể triển khai một số toán tử như == và <,> không?

Cho phép tôi thêm cập nhật cho câu hỏi cổ điển này:

• Thư viện Noda Time của Jon Skeet hiện đã khá hoàn thiện và có một loại chỉ ngày tháng được gọi là LocalDate. (Cục bộ trong trường hợp này chỉ có nghĩa là cục bộ đối với ai đó , không nhất thiết cục bộ đối với máy tính nơi mã đang chạy.)

• Loại chỉ ngày được gọi Datelà một bổ sung được đề xuất cho .NET Core, thông qua dự án corefxlab . Bạn sẽ tìm thấy nó trong System.Timegói, cùng với một TimeOfDayloại và một số phương thức mở rộng cho các loại hiện có.

Tôi đã nghiên cứu vấn đề này một cách đáng kể, vì vậy tôi cũng sẽ chia sẻ một số lý do cho sự cần thiết của những loại này:

1. Có sự khác biệt hợp lý giữa giá trị chỉ ngày và giá trị ngày vào lúc nửa đêm.

   • Không phải mọi ngày địa phương đều có nửa đêm ở mọi múi giờ. Ví dụ: Quá trình chuyển đổi thời gian tiết kiệm ánh sáng ban ngày vào mùa xuân chuyển tiếp của Brazil chuyển đồng hồ từ 11:59:59 sang 01:00:00.

   • Ngày-giờ luôn đề cập đến một thời gian cụ thể trong ngày, trong khi chỉ ngày có thể đề cập đến đầu ngày, cuối ngày hoặc toàn bộ phạm vi trong ngày.

2. Việc gắn thời gian vào một ngày có thể dẫn đến việc thay đổi ngày khi giá trị được truyền từ môi trường này sang môi trường khác, nếu múi giờ không được theo dõi cẩn thận. Điều này thường xảy ra trong JavaScript (có Dateđối tượng thực sự là ngày + giờ), nhưng cũng có thể dễ dàng xảy ra trong .NET hoặc trong tuần tự hóa khi dữ liệu được truyền giữa JavaScript và .NET.

3. Việc tuần tự hóa một DateTimetệp với XML hoặc JSON (và những thứ khác) sẽ luôn bao gồm thời gian, ngay cả khi điều đó không quan trọng. Điều này rất khó hiểu, đặc biệt là khi xem xét những thứ như ngày sinh và ngày kỷ niệm, trong đó thời gian không liên quan.

4. Về mặt kiến ​​trúc, DateTimelà một đối tượng giá trị DDD , nhưng nó vi phạm Nguyên tắc duy nhất có trách nhiệm theo một số cách:

   • Nó được thiết kế dưới dạng ngày + giờ, nhưng thường được sử dụng dưới dạng chỉ ngày (bỏ qua thời gian) hoặc chỉ thời gian trong ngày (bỏ qua ngày). ( TimeSpancũng thường được sử dụng cho thời gian trong ngày, nhưng đó là một chủ đề khác.)

   • Các DateTimeKindgiá trị gắn liền với .Kindtài sản tách loại đơn thành ba, TheUnspecified loại thực sự là ý định ban đầu của cấu trúc, và nên được sử dụng theo cách đó. Các Utcloại gắn giá trị đặc biệt với UTC, vàLocal Canh lề loại giá trị với múi giờ địa phương của môi trường.

     Vấn đề với việc có một cờ riêng cho loại là mỗi khi bạn sử dụng một DateTime, bạn phải kiểm tra.Kind để quyết định hành vi nào sẽ thực hiện. Các phương thức khung đều làm được điều này, nhưng những phương pháp khác thường quên. Đây thực sự là một vi phạm SRP, vì loại hiện có hai lý do khác nhau để thay đổi (giá trị và loại).

   • Hai trong số này dẫn đến việc sử dụng API biên dịch, nhưng thường vô nghĩa hoặc có các trường hợp cạnh kỳ lạ do tác dụng phụ gây ra. Xem xét:

     // nonsensical, caused by mixing types
     DateTime dt = DateTime.Today - TimeSpan.FromHours(3);  // when on today??
     
     // strange edge cases, caused by impact of Kind
     var london = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
     var paris = TimeZoneInfo.FindSystemTimeZoneById("Romance Standard Time");
     var dt = new DateTime(2016, 3, 27, 2, 0, 0);  // unspecified kind
     var delta = paris.GetUtcOffset(dt) - london.GetUtcOffset(dt);  // side effect!
     Console.WriteLine(delta.TotalHours); // 0, when should be 1 !!!

Tóm lại, mặc dù a DateTime có thể được sử dụng cho ngày chỉ, nó chỉ nên làm như vậy khi mọi nơi sử dụng nó rất cẩn thận để bỏ qua thời gian và cũng rất cẩn thận để không cố gắng chuyển đổi sang và từ UTC hoặc các Múi giờ.

Tôi nghi ngờ không có Datelớp thuần túy dành riêng vì bạn đã có lớp có DateTimethể xử lý nó. Đang cóDate thể sẽ dẫn đến sự trùng lặp và nhầm lẫn.

Nếu bạn muốn phương pháp tiếp cận tiêu chuẩn, hãy xem thuộc DateTime.Datetính chỉ cung cấp phần ngày của a DateTimevới giá trị thời gian được đặt thành 12:00:00 nửa đêm (00:00:00).

Tôi đã gửi email tới refsrcfeedback@microsoft.com và đó là câu trả lời của họ

Marcos, đây không phải là nơi tốt để hỏi những câu như thế này. Hãy thử http://stackoverflow.com Câu trả lời ngắn gọn là bạn cần một mô hình để đại diện cho một thời điểm và DateTime làm được điều đó, đó là kịch bản hữu ích nhất trong thực tế . Việc con người sử dụng hai khái niệm (ngày và giờ) để đánh dấu mốc thời gian là tùy tiện và không hữu ích để tách biệt.

Chỉ tách ra những nơi được bảo hành, đừng làm mọi việc chỉ vì lợi ích mà làm một cách mù quáng. Hãy suy nghĩ theo cách này: bạn gặp phải vấn đề gì được giải quyết bằng cách tách DateTime thành Ngày và Giờ? Và những vấn đề nào bạn sẽ nhận được mà bạn không có bây giờ? Gợi ý: nếu bạn xem cách sử dụng DateTime trên khuôn khổ .NET: http://referencesource.microsoft.com/#mscorlib/system/datetime.cs#df6b1eba7461813b#references bạn sẽ thấy rằng hầu hết được trả về từ một phương thức. Nếu chúng tôi không có một khái niệm như DateTime, bạn sẽ phải sử dụng các tham số hoặc Tuples để trả về một cặp Ngày và Giờ.

HTH, Kirill Osenkov

Trong email của mình, tôi đã hỏi liệu có phải do DateTime sử dụng TimeZoneInfo để lấy thời gian của máy hay không - trong Now propriety. Vì vậy, tôi muốn nói rằng đó là bởi vì "các quy tắc kinh doanh" quá "khớp", họ đã đồng nhất điều đó với tôi.

Tôi đã tạo cấu trúc Ngày đơn giản cho những lúc bạn cần một ngày đơn giản mà không cần lo lắng về phần thời gian, múi giờ, cục bộ so với utc, v.v.

https://github.com/claycephus/csharp-date

Nếu bạn cần chạy so sánh ngày thì hãy sử dụng

yourdatetime.Date;

Nếu bạn đang hiển thị trên màn hình, hãy sử dụng

yourdatetime.ToShortDateString();

Cho phép tôi suy đoán: Có thể là do cho đến SQL Server 2008 không có kiểu dữ liệu Ngày trong SQL nên sẽ rất khó để lưu trữ nó trong máy chủ SQL ?? Và xét cho cùng thì đó là một Sản phẩm của Microsoft?

Ai biết tại sao nó lại như vậy. Có rất nhiều quyết định thiết kế tồi trong .NET framework. Tuy nhiên, tôi nghĩ rằng đây là một trong những điều khá nhỏ. Bạn luôn có thể bỏ qua phần thời gian, vì vậy ngay cả khi một số mã quyết định có DateTime đề cập đến nhiều thứ hơn là chỉ ngày, thì mã quan tâm chỉ nên xem phần ngày. Ngoài ra, bạn có thể tạo một kiểu mới chỉ đại diện cho ngày tháng và sử dụng các hàm trong DateTime để thực hiện các công việc nặng nhọc (tính toán).

Tại sao? Chúng ta chỉ có thể suy đoán và nó không giúp ích gì nhiều để giải quyết các vấn đề kỹ thuật. Một dự đoán tốt là nó DateTimechứa tất cả các chức năng mà một cấu trúc như vậy sẽ có.

Nếu nó thực sự quan trọng với bạn, chỉ cần bọc DateTimetrong cấu trúc bất biến của riêng bạn mà chỉ hiển thị ngày (hoặc xem thuộc DateTime.Datetính).

Ngoài câu trả lời của Robert, bạn cũng có DateTime.ToShortDateStringphương pháp. Ngoài ra, nếu bạn thực sự muốn một đối tượng Ngày, bạn luôn có thể sử dụng mẫu Bộ điều hợp và bọc đối tượng DateTime chỉ hiển thị những gì bạn muốn (tức là tháng, ngày, năm).

Luôn luôn có DateTime.Datetài sản cắt bỏ phần thời gian của DateTime. Có thể bạn có thể đóng gói hoặc bọc DateTime trong kiểu Ngày của riêng mình.

Và đối với câu hỏi tại sao, tôi đoán bạn sẽ phải hỏi Anders Heljsberg.

Bởi vì để biết ngày, bạn phải biết thời gian của hệ thống (tính bằng tích tắc), bao gồm cả thời gian - vậy tại sao lại vứt bỏ thông tin đó?

DateTimecó một Datetài sản nếu bạn không quan tâm đến thời gian.

Yeah, System.DateTime cũng được niêm phong. Tôi đã thấy một số người chơi trò chơi này bằng cách tạo một lớp tùy chỉnh chỉ để nhận giá trị chuỗi của thời gian như đã đề cập trong các bài viết trước đó, những thứ như:

class CustomDate
{
    public DateTime Date { get; set; }
    public bool IsTimeOnly { get; private set; }

    public CustomDate(bool isTimeOnly)
    {
        this.IsTimeOnly = isTimeOnly;
    }

    public string GetValue()
    {
        if (IsTimeOnly)
        {
            return Date.ToShortTimeString();
        }

        else
        {
            return Date.ToString();
        }
    }
}

Điều này có thể không cần thiết, vì bạn có thể dễ dàng giải nén GetShortTimeString từ một kiểu DateTime cũ đơn thuần mà không cần một lớp mới

Nếu bạn sử dụng thuộc tính Ngày hoặc Hôm nay để chỉ lấy phần ngày từ đối tượng DateTime.

DateTime today = DateTime.Today;
DateTime yesterday = DateTime.Now.AddDays(-1).Date;

Sau đó, bạn sẽ chỉ nhận được thành phần ngày với thành phần thời gian được đặt thành nửa đêm.