119: Data Types: DateTimes Part 2.

Dates and times are a lot more complicated than we normally realize. Having a specific data type to manage all the details is crucial. This episode explains the following topics related to time: What is UTC and the difference between coordinated universal time, UTC, and Greenwich Mean Time, GMT. How to handle midnight and noon. How to specify time zones and what it means when the time zone is unspecified. How to work with and read aloud 24 hour time formats. How to specify fractional time units. For example, how to write a time that includes microseconds. How to work with leap seconds. How to combine dates and times into a DateTime format. How to specify date and time intervals. Listen to the full episode or you can also read the full transcript below. Transcript This episode continues the explanation of DateTime data types with the time portion. You might think, how hard can it be to tell the time? Like most other everyday topics, there’s a lot more to consider when the scope goes beyond your immediate geographical boundaries. In the case of times, getting this wrong can cause your program to reject valid dates or even crash. I was planning to finish this topic with this episode, but there’s still too much to cover. So today will explain how to represent times in a written format just like I explained for dates. The fact that it takes an entire episode just to explain how to write a time should give you some insight into the complexities involved. First of all, we have time zones and they’re not all in one hour increments. Then there’ll be cases where the time is in coordinated universal time or UTC for short. This is another example where the letters don’t match the full name but at least here, we know why. UTC is the common and agreed on abbreviation for all languages. Then we need to consider 24 hour clocks vs. using am and pm. And is there a difference between the times 24:00 and 00:00? Does midnight belong to the day before or the next day? We all know about leap years where an extra day gets added to February. But did you know there are leap seconds? It’s details like these that we tend to ignore or clarify in everyday use. The uncertainty and ambiguity have no place in a DateTime data type. Okay, so how does the ISO 8601 standard say that times should be written to avoid any misunderstanding? The hours come first with two digits. If the time is 2 o’clock, don’t write just a 2, write a 02. The minutes are next also using 2 digits and then the seconds with 2 digits. You can have colons between the hours and minutes or not. Don’t use dashes like the date. And even if you live in a locale that normally uses dots, stick to the standard and use colons. The reason colons are used is because any of the units of time, hours, minute, or seconds can have a fractional part after it and that fractional part begins with a decimal separator. The standard allows either a comma or a dot here. If dots were used to separate the units, then that could be confused with the beginning of a fractional part. Once you begin a fractional part, then the remaining units if any should not be specified. In other words, don’t try to say 1.5 hours and 3 minutes. That even sounds strange. There’s no limit for how many digits you can use for the fractional part. For example, if you wanted to represent one microsecond after 10 30, then that would be written as 10:30:00.000001. Just like how you can leave of portions of the date to be less precise, you can also leave off portions of the time. Make sure to leave off the smallest units. This means you can’t have a time with just minutes. You can have a time with just hours. Or just hours and minutes. Or just hours, minutes, and seconds. Putting this together with the last point, if you wanted to represent 10 30 itself leaving off the seconds, then you could either write 10:30 or you could also write 10.5. The reason all this must be