Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Timing is Everything

By Steve Jones, 2010/02/26

Total article views: 180 | Views in the last 30 days: 1

http://www.worldservicegroup.com/images/tzmap.jpgI saw a post asking if an application ought to store time data as UTC and handle conversions on the client, or should they store data as the client inserts it. I suppose the answer is "it depends", but should we have this decision? Shouldn't we just always store time data as UTC based and convert it at the client?

Dealing with times, time zones, and the proper way to calculate data is complicated. We recently had a question of the day that asked if times were equivalent, given different numerical times across time zones, and there was quite a debate as to whether the times given were actually equivalent or equal.  That was a frustrating debate for me to referee and I am very hesitant to allow other questions dealing with time zones for the time being.

For this Friday's poll, I wanted to ask the question of the rest of you and understand how the rest of you look at time values and their impact on our applications. Let us know your answer to this question:

Should we always store time values as UTC in SQL Server?

It might sound a little silly, a little outrageous to store all time values as some reference time and then offset the hours by a time zone. After all, you could even be offsetting by a date as well if enough time zones are crossed. However I think there might be some merit in this.

While almost all applications I've dealt with stored date times as local time, there were occasions where users in different time zones accessed the application. And we hadn't planned for it. It didn't always cause problems, but if we had stored all data as UTC, as a reference time, we would never have confusion. At least not in the data stored. I supposed that applications might still have to decide what local time to use when inserting data, but the server would have have the question of a row of data being EST or CST.

As we grow more interconnected, with users across the globe accessing our applications, I think there becomes a need for a standard time storage mechanism. I'm actually surprised that more auditing organizations haven't required it. After all, if you are trying to determine when a sale took place, or a system access occurred, it shouldn't  ever have the chance of being off by an hour or more.

Steve Jones


The Voice of the DBA Podcasts

Everyday Jones

The podcast feeds are available at sqlservercentral.mevio.com. You can also follow Steve Jones on Twitter:

Overall RSS Feed: or now on iTunes!

Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.

By Steve Jones, 2010/02/26

Total article views: 180 | Views in the last 30 days: 1
Your response
 
 
Related Articles
BLOG

Technical Podcasts I Listen To

There are a few podcasts I tend to listen to as I have time. Since I work with a wide...

ARTICLE

Podcast Announcements

Podcast Feeds

BLOG

Powerscripting Podcast 2

I was interviewed by Jon (@JonWaltz) and Hal (@Halr9000) in episode 106 of the PowerScripting Podcas...

FORUM

DTS / Stored Procedure / Job - Question

DTS / Stored Procedure / Job - Question

FORUM

Podcast Problem

Podcast Problem Blocked by group policy

Tags
editorial    
friday poll    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones