What are the pros and cons have having all/most of your server in UTC? It would certainly help in reporting and centralized logging. Also with event correlation for troubleshooting or security auditing. One also wouldn't have to worry as much about Daylight Saving Time changes. Time.is automatically displays the time in your time zone by using your IP address to detect your location. Your IP address is 22.214.171.124. Your detected location is New York, United States.
Many>- continued -
What is UTC?
UTC, or Coordinated Universal Time, is the standard international time that all time zones are expressed as offsets of. UTC does not get adjusted for daylight savings. To compute local time from UTC, simply add the time zone offset and then add an additional hour if daylight savings time is in effect.
As I write this sentence, the time in UTC is Friday, August 3, 2007 18:18:36. California has a UTC offset of -8 and is in daylight savings time. Therefore my local time is Friday, August 3, 2007 11:18:36. To compute the local time I simply subtracted eight hours then added an hour back in for daylights savings.
Why and When You Should Use UTC
UTC should be used in situations when date/time values are automatically entered by the system to record when a record was added or last updated. For example, in an eCommerce website, when an order was placed you'd want to record the date and time the order was made.
The primary advantage of storing date/time values in UTC is that it makes the data transportable. To see what I mean, imagine that following scenario: you have an eCommerce website that is being hosted in a web server located in the Pacific time zone (UTC -8) and this application stores the date and time orders were placed in server time. Say a user, Bob, makes an order on August 1, 2007 at 9:00 AM UTC -8. After many months of phenomenal growth, you decide to switch to a larger web hosting company, one on the east coast where the time zone is UTC -5. Since the date/time is stored in server time, Bob's previous order still shows that it was made on August 1 2007 at 9:00 AM. But since we are now in UTC -5, it is as if Bob's order was made three hours earlier than it really was (since when it was 9:00 AM on August 1, 2007 in the west coast it was really 12:00 noon on the east coast).
One way around this, you might contend, is to execute a SQL query that adds three hours to the order date for all records in the table. Something like:
And such an approach would suffice.. for this situation. But imagine that you moved to a web hosting company situated in the US state of Arizona, where daylight savings is not observed. Eep. Now you would have to write a more complex
UPDATE statement that adjusted the hours based on whether the order date fell within daylight savings. Ick.
Another pitfall of server time is if you have multiple servers in multiple time zones. Now the values for each server's date/time fields is relative to that server's geographical location. What UTC buys you is a single reference point.
Other Challenges of Date/Time Values
There are numerous other date/time-related challenges that I am going to ignore at this point. The thrust of this article is to highlight UTC, how to use it in your border='0'>
' VB (use instead of DateTime.Now)
Dim currentTime As DateTime = DateTime.UtcNow
// C# (use instead of DateTime.Now)
DateTime currentTime = DateTime.UtcNow;
For SQL Server, use the
Converting from UTC Time to Server Time
Given a time in UTC, the .NET Framework makes it easy to convert it to server time. Just use the DateTime class's
ToLocalTime()method, like so:
Utc Time Server
A Complete Example
To further illustrate using UTC to store auto-entered date/time values, let's examine a sample application that has fields to track when a record was created and last updated. This application, which is available at the end of this article, has a single database table,
Utc Server Time, with a very simple schema:
Utc Server Ip Address
In the download you'll find a single ASP.NET page,
UTCFunctions.aspx, that contains a DetailsView control for adding new employees and a GridView for listing and editing existing employees. Both are wired up to a SqlDataSource on the page that contains the associated
DELETE statements. (For more information on working with data in ASP.NET 2.0, see my multi-part article series Accessing and Updating Data in ASP.NET 2.0.)
As you can see from the screen shot above, the DetailsView does not allow the user to enter values for the
DateUpdated fields. Instead, it populates these with the current date/time in UTC. The
INSERT statement used by the SqlDataSource control follows:
DateUpdated value, the built-in SQL Server function
getutcdate() is used. For the
DateCreated value, a parameter is specified (
@DateCreated) and its value is specified programmatically in the DetailsView control's
ItemInserting event handler:
I used both techniques -
DateTime.UtcNow - to illustrate both options. Eve online python. In practice you'd probably want to choose one approach and use it for both parameters.
The GridView displays the
DateCreated values in UTC time. These are the raw values from the database. The two fields' values are also converted to local time and displayed in columns in the grid. This conversion is done using the
ToLocalTime method. In particular, a TemplateField is used to show the local times and the
ToLocalTime method is used directly within the Label control's
Lastly, note that the GridView's editing interface does not allow the date fields to be modified. Whenever a record is edited the
DateUpdated field is updated to the current date/time (in UTC) via the
UTC time provides a universal point of reference by which all time zones are offsetted from. Therefore, UTC is an ideal choice for storing date/time formats in a web application when the web server and its users might reside in different time zones. Things like daylight savings further complicate working with dates and times, but UTC does not observe any time zone, simplifying things a tiny bit. In short, working with dates and times in a web application is one of those things that is harder than it should be and has a lot of wrinkles that make the whole thing a bit of a mess. One step in the right direction, however, is to make sure you are storing auto-entered timestamp-like date and time values in UTC rather than in server time.
For guidance on displaying date and time values, see Advice for Storing and Displaying Dates and Times Across Different Time Zones.
Happy Programming!By Scott Mitchell