pointers, solutions and scripts for the SQL DBA
not intended to replace msdn, common sense or oxford commas

Thursday, September 14, 2017

Twilight Timezone: Date and Time Architecture in your Applications aka Use DateTimeOffset, Your Future Self Thanks You

Thanks to everyone at a joint meeting of the Baton Rouge .NET and SQL Server User Groups who joined my colleague Steve Schaneville and me for a presentation on date/time data architecture in modern applications last night.

We reviewed the SQL and .NET architecture for date/time storage an informative and thought-provoking talk about handling timezones in your application architecture. Dealing with Time Zones is disconcerting, rarely straightforward, and often complicated! In the end, our architecture recommendations lead to two likely best paths - either using datetimeoffset (and optionally also storing the Time Zone Name information in a separate field) or storing the date and time in separate fields. (But preferably datetimeoffset.) There are few advantages and major disadvantages to storing only UTC data or all-in-one time zone data.

Steve and I are the principal consultants for appdev and SQL Server respectively at Sparkhound, and have worked hard to put together a joint presentation on this topic that is valuable to both audiences. We got a lot of great questions and positive feedback, as well as more notes to add to our presentation the next time, which will likely be at Houston Tech Fest 2017 in October. Got questions/feedback for us, actual use cases or lessons learned? Please reach out to us, our emails are at the end of the slide deck below.

You can download the slidedeck and sample code here.

UPDATE: Related to Steve and I's presentation on date time architecture, check out our colleague Vance's blog post on serialization: http://www.sparkhound.com/learn/blog/date-demo-blog