Video is a lecture about how to think about dates and times, through the lens of a specific open source .NET library designed to aid with applying that thinking. It points out how most languages’ standard libraries really work against you, because they conflate different concepts. For example, an Instant (a specific point in time, globally recognised) and a LocalDateTime (a date and time in a way that is irrespective of your location—for example you might want your alarm to wake you at 8:00 am on weekdays, and still do that if you move to a different time zone), a ZonedDateTime (a date and time tied to a specific location—like if you want to say “the meeting starts at 10:00 am Oslo Time”), and an OffsetDateTime (a date and time tied to a specific UTC offset—which is not necessarily the same as a time zone, because “Oslo Time” is a time zone that doesn’t change, but its UTC offset might change if they go in or out of DST, or if a place decides to change, like how Samoa changed from UTC-11 to UTC+13 in 2011.
These are all subtly different concepts which are useful in different cases, but most libraries force you to use a single poorly-defined “DateTime” class. It’s easier and requires less thought, but is also much more likely to get you into trouble as a result, precisely because of that lack of thought, because it doesn’t let you make a clear distinction about what specifically it is.
Dates and times aren’t that hard—honestly!
Video is a lecture about how to think about dates and times, through the lens of a specific open source .NET library designed to aid with applying that thinking. It points out how most languages’ standard libraries really work against you, because they conflate different concepts. For example, an
Instant
(a specific point in time, globally recognised) and aLocalDateTime
(a date and time in a way that is irrespective of your location—for example you might want your alarm to wake you at 8:00 am on weekdays, and still do that if you move to a different time zone), aZonedDateTime
(a date and time tied to a specific location—like if you want to say “the meeting starts at 10:00 am Oslo Time”), and anOffsetDateTime
(a date and time tied to a specific UTC offset—which is not necessarily the same as a time zone, because “Oslo Time” is a time zone that doesn’t change, but its UTC offset might change if they go in or out of DST, or if a place decides to change, like how Samoa changed from UTC-11 to UTC+13 in 2011.These are all subtly different concepts which are useful in different cases, but most libraries force you to use a single poorly-defined “
DateTime
” class. It’s easier and requires less thought, but is also much more likely to get you into trouble as a result, precisely because of that lack of thought, because it doesn’t let you make a clear distinction about what specifically it is.