Un type pour Date uniquement en C # - pourquoi n'y a-t-il pas de type Date?

Dans notre projet C #, nous avons besoin de représenter une date sans heure. Je connais l'existence du DateTime, cependant, il intègre également une heure de la journée. Je veux préciser que certaines variables et certains arguments de méthode sont basés sur la date . Par conséquent, je ne peux pas utiliser la DateTime.Datepropriété

Quelles sont les approches standard de ce problème? Je ne suis sûrement pas le premier à rencontrer cela? Pourquoi n'y a-t-il pas de Dateclasse en C #?

Quelqu'un a-t-il une belle implémentation en utilisant une structure et peut-être des méthodes d'extension sur DateTime et peut-être implémentant certains opérateurs tels que == et <,>?

Permettez-moi d'ajouter une mise à jour à cette question classique:

• La bibliothèque Noda Time de Jon Skeet est maintenant assez mature et a un type de date uniquement appelé LocalDate. (Local dans ce cas signifie simplement local pour quelqu'un , pas nécessairement local pour l'ordinateur sur lequel le code est exécuté.)

• Un type de date uniquement appelé Dateest un ajout proposé au .NET Core, via le projet corefxlab . Vous le trouverez dans le System.Timepackage, avec un TimeOfDaytype et plusieurs méthodes d'extension aux types existants.

J'ai étudié ce problème de manière significative, je vais donc également partager plusieurs raisons de la nécessité de ces types:

1. Il existe un écart logique entre une valeur de date uniquement et une valeur de date à minuit.

   • Pas tous les jours locale a un minuit dans chaque fuseau horaire. Exemple: la transition de l'heure d'été vers l'avant du Brésil fait passer l'horloge de 11:59:59 à 01:00:00.

   • Une date-heure fait toujours référence à une heure spécifique dans la journée, tandis qu'une date uniquement peut faire référence au début de la journée, à la fin de la journée ou à toute la plage de la journée.

2. Le fait d'attacher une heure à une date peut entraîner un changement de date lorsque la valeur est transmise d'un environnement à un autre, si les fuseaux horaires ne sont pas surveillés très attentivement. Cela se produit généralement en JavaScript (dont l' Dateobjet est en réalité une date + heure), mais peut également se produire facilement dans .NET, ou dans la sérialisation lorsque les données sont transmises entre JavaScript et .NET.

3. La sérialisation d'un DateTimeavec XML ou JSON (et autres) inclura toujours l'heure, même si ce n'est pas important. C'est très déroutant, surtout si l'on considère des choses comme les dates de naissance et les anniversaires, où l'heure n'a pas d'importance.

4. Sur le plan architectural, il DateTimes'agit d'un objet de valeur DDD , mais il enfreint le principe de responsabilité unique de plusieurs manières:

   • Il est conçu comme un type date + heure, mais est souvent utilisé comme date uniquement (en ignorant l'heure), ou en heure uniquement (en ignorant la date). ( TimeSpanest également souvent utilisé pour l'heure de la journée, mais c'est un autre sujet.)

   • La DateTimeKindvaleur attachée à la .Kindpropriété divise le type unique en trois. Le Unspecifiedgenre est vraiment l'intention d'origine de la structure et doit être utilisé de cette façon. Le Utckind aligne la valeur spécifiquement avec UTC et le Localkind aligne la valeur sur le fuseau horaire local de l'environnement.

     Le problème d'avoir un indicateur distinct pour kind est que chaque fois que vous consommez un DateTime, vous êtes censé vérifier .Kindpour décider du comportement à adopter. Les méthodes de cadre font toutes cela, mais d'autres oublient souvent. Il s'agit vraiment d'une violation SRP, car le type a maintenant deux raisons différentes de changer (la valeur et le genre).

   • Les deux conduisent à des utilisations d'API qui se compilent, mais qui sont souvent absurdes, ou ont des cas extrêmes causés par des effets secondaires. Considérer:

     // 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 !!!

En résumé, alors que a DateTime peut être utilisé pour une date uniquement, il ne devrait le faire que lorsque chaque lieu qui l'utilise fait très attention d'ignorer l'heure, et est également très prudent de ne pas essayer de convertir vers et depuis UTC ou autre fuseaux horaires.

Je soupçonne qu'il n'y a pas de Dateclasse pure dédiée car vous avez déjà DateTimequi peut le gérer. Cela Dateentraînerait des doubles emplois et de la confusion.

Si vous voulez l'approche standard, regardez la DateTime.Datepropriété qui donne uniquement la partie date de a DateTimeavec la valeur de l'heure définie sur 12:00:00 minuit (00:00:00).

J'ai envoyé un e-mail à refsrcfeedback@microsoft.com et c'est leur réponse

Marcos, ce n'est pas un bon endroit pour poser des questions comme celles-ci. Essayez http://stackoverflow.com La réponse courte est que vous avez besoin d'un modèle pour représenter un point dans le temps, et DateTime le fait, c'est le scénario le plus utile en pratique . Le fait que les humains utilisent deux concepts (date et heure) pour marquer des points dans le temps est arbitraire et inutile à séparer.

Découpez seulement là où c'est justifié, ne faites pas les choses juste pour le plaisir de faire les choses à l'aveuglette. Pensez-y de cette façon: quel problème avez-vous qui est résolu en divisant DateHeure en Date et Heure? Et quels problèmes aurez-vous que vous n'avez pas maintenant? Astuce: si vous regardez les utilisations de DateTime dans le framework .NET: http://referencesource.microsoft.com/#mscorlib/system/datetime.cs#df6b1eba7461813b#references Vous verrez que la plupart sont renvoyés par une méthode. Si nous n'avions pas un seul concept comme DateTime, vous devrez utiliser des paramètres out ou des tuples pour renvoyer une paire de date et d'heure.

HTH, Kirill Osenkov

Dans mon e-mail, je me suis demandé si c'était parce que DateTime utilise TimeZoneInfo pour obtenir l'heure de la machine - dans Now propriété. Donc je dirais que c'est parce que "les règles métier" sont "trop ​​couplées", ils me l'ont confirmé.

J'ai créé une structure de date simple pour les moments où vous avez besoin d'une date simple sans vous soucier de la partie horaire, des fuseaux horaires, du local ou de l'utc, etc.

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

Si vous devez exécuter des comparaisons de dates, utilisez

yourdatetime.Date;

Si vous affichez à l'écran, utilisez

yourdatetime.ToShortDateString();

Permettez-moi de spéculer: c'est peut-être parce que jusqu'à SQL Server 2008, il n'y avait pas de type de données Date dans SQL, donc il serait difficile de le stocker dans SQL Server ?? Et c'est après tout un produit Microsoft?

Qui sait pourquoi c'est ainsi. Il y a beaucoup de mauvaises décisions de conception dans le framework .NET. Cependant, je pense que c'est une question assez mineure. Vous pouvez toujours ignorer la partie heure, donc même si un code décide de faire référence à une date / heure plus que juste la date, le code qui se soucie ne devrait jamais regarder que la partie date. Vous pouvez également créer un nouveau type qui ne représente qu'une date et utiliser des fonctions dans DateTime pour effectuer le gros du travail (calculs).

Pourquoi? Nous ne pouvons que spéculer et cela ne fait pas grand-chose pour résoudre les problèmes d'ingénierie. Une bonne supposition est que DateTimecontient toutes les fonctionnalités qu'une telle structure aurait.

Si cela compte vraiment pour vous, enveloppez simplement DateTimevotre propre structure immuable qui expose uniquement la date (ou regardez la DateTime.Datepropriété).

En plus de la réponse de Robert, vous avez également la DateTime.ToShortDateStringméthode. De plus, si vous vouliez vraiment un objet Date, vous pouvez toujours utiliser le modèle Adapter et envelopper l'objet DateTime en exposant uniquement ce que vous voulez (c'est-à-dire le mois, le jour, l'année).

Il y a toujours la DateTime.Datepropriété qui coupe la partie temporelle du DateTime. Vous pouvez peut-être encapsuler ou encapsuler DateTime dans votre propre type de date.

Et pour savoir pourquoi, eh bien, je suppose que vous devrez demander à Anders Heljsberg.

Parce que pour connaître la date, vous devez connaître l'heure du système (en ticks), qui comprend l'heure - alors pourquoi jeter ces informations?

DateTimea une Datepropriété si vous ne vous souciez pas du tout de l'heure.

Ouais, System.DateTime est également scellé. J'ai vu des gens jouer à des jeux avec cela en créant une classe personnalisée juste pour obtenir la valeur de chaîne de l'heure comme mentionné dans les articles précédents, des trucs comme:

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();
        }
    }
}

Ceci est peut-être inutile, car vous pouvez facilement extraire GetShortTimeString d'un ancien type DateTime sans nouvelle classe

Si vous utilisez les propriétés Date ou Today pour obtenir uniquement la partie date de l'objet DateTime.

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

Ensuite, vous obtiendrez le composant de date uniquement avec le composant d'heure défini sur minuit.