C# – Why isn’t there a data type for just a date

cnet

One of the first things I learned about dates and times in c# (and various other languages) is that a date is stored as a DateTime with the time component set to midnight. There is no difference between "Jan 1, 2017" and "January 1, 2017 00:00:00.000". If you need to display just a date, you can use formatting functions like ToString to remove the time portion.

This seems to cause a lot of problems, a few of which I shall list here:

  1. DateTime takes up more storage space than needed: 8 bytes instead of the 3 required for a simple date.

  2. Use of 00:00:00 for "no date" conflates "a known value of 0" with "unknown value." This seems rather noobish, in the same way a new programmer might confuse a null string with an empty string. Null and empty are different, and "no time" and "midnight" are different ideas.

  3. You see idioms like this one poppping up, even in relatively simple comparisions:

    if (startDate >= myDateTime && myDateTime < endDate.AddDays(1))

    or

    if (startDateTime >= myDate && myDate <= endDateTime.Date)

    instead of a far simpler

    if (startDate >= myDate && myDate <= endDate)

  4. When system components located in different time zones call each other over web services, and the schema for those web services is generated from c# types, a time element can be introduced (so that the resulting date occurs early in the morning), or the date value actually may shift by a day (e.g. the final date is actually the prior day at a time late in the evening). This can make it painful to transmit values that are agnostic with respect to timezone, e.g. a date of birth, or a credit card expiration date.

SQL Server has a Date type that stores only month, day, and year.

XSD specifies different data types for Date, Time, and DateTime.

Why doesn't c# have such a type?

How do you work around it? For example, can c# properties be attributed so that they will serialize as a Date instead of a DateTime?

Best Answer

What is a Date?

Let's say It's noon at your local region. You'll look at your clock and see something like 22/03/2017 12:00. You could say easily that this is the current date for everyone else in the world, right?

Well, not really. Chances are, if you are in London, or say, Russia, or the United States, your clock isn't really correct regarding those places. Your clock is marking the wrong time for the rest of the world, and for some places even the wrong date. When you talk about "the world", having a date without a time makes little to no sense once you start considering people outside your timezone. Just think how annoying it is to go to a foreigner website and seeing that, somehow, the user generated content there is coming from the future. That's what happens when you don't take into account timezones!

That's where C# DateTime goes in.

DateTime isn't the usual simple date you may need for local, just-my-company software. It is a somewhat powerful data structure that had the intent to be able to provide Universal Coordinated Time to any app. The magic part of the DateTime structure is that, with minor fiddling, you can make it display the correct DateTime for every single place in the world.

The idea behind DateTime was to provide not a simple Date object, but something you could use to represent dates all over the world, even with different Time Zones. It was made thinking in global applications, and thus it was designed with a bunch of extra functionalities that may not have apparent utility at first glance, but nevertheless can save a lot of time from people developing applications that will have to deal with variable time zones.

It is far from perfect, yes, but it does what it was meant for - representing Time in a universal, and somewhat portable, way.

So, in a sense, when using C# you are forced to consider times when developing your app, not only dates. And, really, that's a good thing - a DateTime is a reference point in time relative to something, and when you change your point of reference, the value for that DateTime must act accordingly.

To be totally fair, I think C# is one of the languages that got this thing right. You can have a Time interval without a date (TimeSpan is there for that), but you can't really have a meaningful date on a global scope without a reference frame and a time attached to it. I didn't like DateTime at all when I first met the language, but after having to develop an App with multiple timezones I understood why this design choice was actually a smart one.

Related Topic