date and time Archives : Global Nerdy

Swift (or more accurately, the Foundation framework from which Swift gets its date and time classes) gets a bad rap for complex date and time programming, but that’s because date and time programming is complex, and many programmers have erroneous ideas on the topic.

This blog used to be home to a four-part series on date and time programming in Swift. I’ve recently updated that series and moved it to the Auth0 Developer Blog (the one that has much greater reach and also pays my mortgage). It’s also a four-parter:

Introduction to Date and Time Programming in Swift, Part 1: Learn how to create dates and times using Swift’s powerful date and time objects.
Introduction to Date and Time Programming in Swift, Part 2: Now that you can create dates and times in Swift, learn how to display date and time values to your users.
Date and Time Calculations in Swift, Part 1: Learn how to perform date and time calculations with Swift’s powerful date and time objects.
Date and Time Calculations in Swift, Part 2: Improve your Swift date and time calculations with syntactic magic.

With these articles, you’ll be able to answer questions like:

What will the day and time be 10,000 hours into 2023?
What date is the first Friday of 2024?
What date is the first National Donut Day of 2023?
What date is the Thursday of the 33rd week of the year?
What is the actual date of September 50, 2023?
What day of the week and week of the year will April Fools’ Day 2023 fall on?
What’s 3:30 p.m. Pacific on the 3rd Thursday of July in the Coptic Calendar system in Melbourne, Australia’s time zone?
When does a 90-day warranty that starts today expire?
What is the date of the next Sunday? Or the previous Sunday?
When is the next Friday the 13th? How many Friday the 13ths will there be in 2024?
Can you write code like this:

let futureDate = (2.months + 3.days + 4.hours + 5.minutes + 6.seconds).fromNow

I answer all of these questions in this series, so check these articles out!

Tired: DateTime. Wired: DateTimeOffset!

You’d think that with 10,000 years of date- and time-keeping under our belts, it would be easy to keep track of dates and times in a modern-day database. It’s a little trickier than you might think, according to The Death of DateTime?, an article in Bart Duncan’s SQL Weblog.

The gist of the article is pretty simple: if you’re using SQL Server 2008 and want to store dates and times unambiguously, use the datetimeoffset type (introduced in SQL Server 2008) rather than the traditional datetime.

Why? Because datetimeoffset is datetime with these key differences:

The time value is stored internally in an unambiguous UTC format
The local time zone offset is stored along with the UTC time
It is capable of storing more precise times than datetime

Duncan recommends that if you’re storing data in SQL Server 2008, you should almost always store date-and-time values in datetimeoffset rather than datetime. It’s a good idea; I’d go even farther and suggest that if you’re programming using .NET 3.5, you should make use of the corresponding DateTimeOffset type instead of DateTime. You can read more about .NET 3.5’s DateTimeOffset type in this entry in Dan Rigsby’s blog titled DateTime vs. DateTimeOffset in .NET.

When might you want to use datetime? Duncan suggests that you should use it in those rare cases when you want to store time ambiguously. The example he provides is: “if you wanted a column to record the fact that all stores in a chain should open at 8:00am local time (whatever the local time zone may be), you should use datetime.”

Thanks to Brent Ozar for the link!