120: Data Types: DateTimes Part 3 C#.

So you think you know how to use the DateTime struct in C#? You might be surprised. C# provides a struct which is a value type called DateTime that implements various interfaces including IComparable, IConvertible, IFormattable, and ISerializable. Internally, it’s just a 64 bit integer. That’s it. All the functionality that I’ve explained in the last two episodes relies on just 64 bits. And really, the DateTime uses just 62 of these bits for the actual date and time. The last 2 bits are used to identify what kind of DateTime this is. The DateTime struct has no concept of a timezone. Sure, it can track if it’s local or not. But local to where? Microsoft tried to fix this in .Net 2.0 with the DateTimeOffset struct which allows you to specify a local date and time that’s tied to a specific offset from UTC. That seems great. But even the DateTimeOffset struct has problems because while it’s good at specifying a particular instant that’s clear exactly when it occurred, it has no way of knowing what the time will be even a minute later. That’s because you need more than just an offset to know how time should be handled. You really need to know which time zone the DateTimeOffset represents. Only then can you determine if daylight savings time is about to begin or not. For this, you do have a new TimeZoneInfo class but it remains disconnected from the DateTime and DateTimeOffset structs. It’s very easy to get things mixed up. Listen to the full episode for more or you can read the full transcript below. Transcript This episode continues the explanation of DateTime data types. We’re getting to actual implementations now and languages tend to have very different notions of how to deal with dates and times. This episode will describe the C# version of DateTime. C# provides a struct which is a value type called DateTime that implements various interfaces including IComparable, IConvertible, IFormattable, and ISerializable. Internally, it’s just a 64 bit integer. That’s it. All the functionality that I’ve explained in the last two episodes relies on just 64 bits. And really, the DateTime needs just 62 of these bits for the actual date and time. The last 2 bits are used to identify what kind of DateTime this is. There are four options although the documentation usually only mentions 3 of these. I’ll come back to this in a moment. The majority of bits form a potentially really big number. What could possibly need such a large number? You see, the DateTime doesn’t store its value in text. It doesn’t store for example 2020-07-01T12:30Z. What it does is keep track of how many 100 nanosecond intervals have passed since midnight zero hours of January 1st of the year 1 in the Gregorian calendar. That’s why it needs such a large number. There’ve been a lot of 100 nanoseconds since then. Here’s something I always wondered. Why the year 1? Well, it turns out that there is no year 0 in the Gregorian calendar. That still seems strange to me. I mean, when a person is born they have to go through a whole year, learning how to sit, crawl, and sometimes walk before the first birthday. But that’s the way the calendar works. It brings up an interesting question. In what year should new centuries begin? If the first year was 1, then the second century should start at the year 101 instead of 100. Our current century should have started in the year 2001 based on this. What do you do if you want to work with dates before year 1? You’re on your own there. You’ll have to make your own class or struct to store the information. You probably don’t need to worry about 100 nanosecond intervals anymore. So that should make it a bit easier. I’ll mention also that if you ever want to store a DateTime in a SQLServer database, just be aware that SQLServer has a much more limited idea of a DateTime and can only go back to the year 1