A Date type

[Korporal]

I'm wondering if there might be traction for introducing a new Date struct. The motivation being that although we can easily represent dates with DateTime, that type does expose methods that are unrelated to dates, for example AddHours and many parse methods that can accept time related values.

The goal is that a Date instance never has any time component or time zone info, one cannot add seconds or hours or copy a DateTime to it and inadvertently carry time data over.

A date would always be just a Date with no scope for accidental time data creeping in.

Thoughts?

[Clockwork-Muse]

Duplicate of #39816 , and so many other issues.

[Clockwork-Muse]

Outside of that, if you're doing a lot of date/time related work, I really recommend you grab NodaTime and use a sane date/time library.

[Korporal]

@Clockwork-Muse - Thanks and yes it seems this is already actively under discussion. I've become more critical of many open source libraries these past few years, I always begin such an undertaking by visiting the GitHub issues list and always find a lengthy list of problems. When one starts to use a library one never really knows if one will hit a problem that takes time to resolve or how receptive the developers are to issue reports and so on.

Many of the issues I see for NodaTime have been actively under discussions for years, this is always a source of risk for projects.

[Clockwork-Muse]

.... you think closed source projects are any different? And due to how widely used .NET is, we can be very resistant to some ideas.

NodaTime's issue list is rather small, and most of them are for enhancements for additional features.

[reflectronic]

There is already something like this in the System.Time corefxlab experiment:

System.Time. This project augments the date and time APIs in .NET. It adds two new core types: Date and Time. These types will ultimately be submited for inclusion in System.Runtime.

[Clockwork-Muse]

@reflectronic - Yes, that's mentioned in the duplicate issue.