Clock change on SQL Server

Question

With the clock change ahead in Europe - how does SQL Server deal with the clock change? Are there known issues related to a clock change?

Answer 1

SQL Server just uses the operating system's time. However, if your application code relies on functions like GETDATE(), then your code needs to be able to handle jumps forward (or backward) in time.

For example, if your have code that does something like this:

SET @StartDate = GETDATE()
(Do some work)
IF DATEDIFF(MM, @StartDate, GETDATE()) > 60 ....

That code can fail. Long term, consider using GETUTCDATE() instead and storing dates with DATETIMEOFFSET - but that's a big code change that you can't really do quickly before changing the date on a server.

Answer 2

Your code has to be insulated for that - as Brent says, SQL Server just relies on whatever the operating system says, so it inherits its DST changes, explicit time zone changes, and drift. To avoid issues involving everything (except drift of course), I always put all of my servers - where practical - to UTC. No time zone conversions (that is easy to do at display time, especially if you need to display multiple time zones anyway), and no DST jumps backward or forward.